feat: initial import of Rust implementation of Codex CLI in codex-rs/ (#629)
As stated in `codex-rs/README.md`:
Today, Codex CLI is written in TypeScript and requires Node.js 22+ to
run it. For a number of users, this runtime requirement inhibits
adoption: they would be better served by a standalone executable. As
maintainers, we want Codex to run efficiently in a wide range of
environments with minimal overhead. We also want to take advantage of
operating system-specific APIs to provide better sandboxing, where
possible.
To that end, we are moving forward with a Rust implementation of Codex
CLI contained in this folder, which has the following benefits:
- The CLI compiles to small, standalone, platform-specific binaries.
- Can make direct, native calls to
[seccomp](https://man7.org/linux/man-pages/man2/seccomp.2.html) and
[landlock](https://man7.org/linux/man-pages/man7/landlock.7.html) in
order to support sandboxing on Linux.
- No runtime garbage collection, resulting in lower memory consumption
and better, more predictable performance.
Currently, the Rust implementation is materially behind the TypeScript
implementation in functionality, so continue to use the TypeScript
implmentation for the time being. We will publish native executables via
GitHub Releases as soon as we feel the Rust version is usable.
2025-04-24 13:31:40 -07:00
|
|
|
[workspace]
|
|
|
|
|
members = [
|
2025-09-30 03:10:33 -07:00
|
|
|
"backend-client",
|
feat: initial import of Rust implementation of Codex CLI in codex-rs/ (#629)
As stated in `codex-rs/README.md`:
Today, Codex CLI is written in TypeScript and requires Node.js 22+ to
run it. For a number of users, this runtime requirement inhibits
adoption: they would be better served by a standalone executable. As
maintainers, we want Codex to run efficiently in a wide range of
environments with minimal overhead. We also want to take advantage of
operating system-specific APIs to provide better sandboxing, where
possible.
To that end, we are moving forward with a Rust implementation of Codex
CLI contained in this folder, which has the following benefits:
- The CLI compiles to small, standalone, platform-specific binaries.
- Can make direct, native calls to
[seccomp](https://man7.org/linux/man-pages/man2/seccomp.2.html) and
[landlock](https://man7.org/linux/man-pages/man7/landlock.7.html) in
order to support sandboxing on Linux.
- No runtime garbage collection, resulting in lower memory consumption
and better, more predictable performance.
Currently, the Rust implementation is materially behind the TypeScript
implementation in functionality, so continue to use the TypeScript
implmentation for the time being. We will publish native executables via
GitHub Releases as soon as we feel the Rust version is usable.
2025-04-24 13:31:40 -07:00
|
|
|
"ansi-escape",
|
2025-10-17 11:52:57 -07:00
|
|
|
"async-utils",
|
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`.
2025-09-30 00:06:18 -07:00
|
|
|
"app-server",
|
2026-03-08 18:43:55 -06:00
|
|
|
"app-server-client",
|
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.
2025-09-30 19:16:26 -07:00
|
|
|
"app-server-protocol",
|
2025-11-14 12:39:58 -08:00
|
|
|
"app-server-test-client",
|
2026-01-08 13:40:14 +00:00
|
|
|
"debug-client",
|
feat: initial import of Rust implementation of Codex CLI in codex-rs/ (#629)
As stated in `codex-rs/README.md`:
Today, Codex CLI is written in TypeScript and requires Node.js 22+ to
run it. For a number of users, this runtime requirement inhibits
adoption: they would be better served by a standalone executable. As
maintainers, we want Codex to run efficiently in a wide range of
environments with minimal overhead. We also want to take advantage of
operating system-specific APIs to provide better sandboxing, where
possible.
To that end, we are moving forward with a Rust implementation of Codex
CLI contained in this folder, which has the following benefits:
- The CLI compiles to small, standalone, platform-specific binaries.
- Can make direct, native calls to
[seccomp](https://man7.org/linux/man-pages/man2/seccomp.2.html) and
[landlock](https://man7.org/linux/man-pages/man7/landlock.7.html) in
order to support sandboxing on Linux.
- No runtime garbage collection, resulting in lower memory consumption
and better, more predictable performance.
Currently, the Rust implementation is materially behind the TypeScript
implementation in functionality, so continue to use the TypeScript
implmentation for the time being. We will publish native executables via
GitHub Releases as soon as we feel the Rust version is usable.
2025-04-24 13:31:40 -07:00
|
|
|
"apply-patch",
|
2025-07-28 08:31:24 -07:00
|
|
|
"arg0",
|
2025-10-16 21:03:23 -07:00
|
|
|
"feedback",
|
2026-03-19 20:12:07 -07:00
|
|
|
"features",
|
2025-09-30 03:10:33 -07:00
|
|
|
"codex-backend-openapi-models",
|
Code mode on v8 (#15276)
Moves Code Mode to a new crate with no dependencies on codex. This
create encodes the code mode semantics that we want for lifetime,
mounting, tool calling.
The model-facing surface is mostly unchanged. `exec` still runs raw
JavaScript, `wait` still resumes or terminates a `cell_id`, nested tools
are still available through `tools.*`, and helpers like `text`, `image`,
`store`, `load`, `notify`, `yield_control`, and `exit` still exist.
The major change is underneath that surface:
- Old code mode was an external Node runtime.
- New code mode is an in-process V8 runtime embedded directly in Rust.
- Old code mode managed cells inside a long-lived Node runner process.
- New code mode manages cells in Rust, with one V8 runtime thread per
active `exec`.
- Old code mode used JSON protocol messages over child stdin/stdout plus
Node worker-thread messages.
- New code mode uses Rust channels and direct V8 callbacks/events.
This PR also fixes the two migration regressions that fell out of that
substrate change:
- `wait { terminate: true }` now waits for the V8 runtime to actually
stop before reporting termination.
- synchronous top-level `exit()` now succeeds again instead of surfacing
as a script error.
---
- `core/src/tools/code_mode/*` is now mostly an adapter layer for the
public `exec` / `wait` tools.
- `code-mode/src/service.rs` owns cell sessions and async control flow
in Rust.
- `code-mode/src/runtime/*.rs` owns the embedded V8 isolate and
JavaScript execution.
- each `exec` spawns a dedicated runtime thread plus a Rust
session-control task.
- helper globals are installed directly into the V8 context instead of
being injected through a source prelude.
- helper modules like `tools.js` and `@openai/code_mode` are synthesized
through V8 module resolution callbacks in Rust.
---
Also added a benchmark for showing the speed of init and use of a code
mode env:
```
$ cargo bench -p codex-code-mode --bench exec_overhead -- --samples 30 --warm-iterations 25 --tool-counts 0,32,128
Finished [`bench` profile [optimized]](https://doc.rust-lang.org/cargo/reference/profiles.html#default-profiles) target(s) in 0.18s
Running benches/exec_overhead.rs (target/release/deps/exec_overhead-008c440d800545ae)
exec_overhead: samples=30, warm_iterations=25, tool_counts=[0, 32, 128]
scenario tools samples warmups iters mean/exec p95/exec rssΔ p50 rssΔ max
cold_exec 0 30 0 1 1.13ms 1.20ms 8.05MiB 8.06MiB
warm_exec 0 30 1 25 473.43us 512.49us 912.00KiB 1.33MiB
cold_exec 32 30 0 1 1.03ms 1.15ms 8.08MiB 8.11MiB
warm_exec 32 30 1 25 509.73us 545.76us 960.00KiB 1.30MiB
cold_exec 128 30 0 1 1.14ms 1.19ms 8.30MiB 8.34MiB
warm_exec 128 30 1 25 575.08us 591.03us 736.00KiB 864.00KiB
memory uses a fresh-process max RSS delta for each scenario
```
---------
Co-authored-by: Codex <noreply@openai.com>
2026-03-20 23:36:58 -07:00
|
|
|
"code-mode",
|
2026-01-30 12:03:29 +00:00
|
|
|
"cloud-requirements",
|
2025-09-30 03:10:33 -07:00
|
|
|
"cloud-tasks",
|
|
|
|
|
"cloud-tasks-client",
|
feat: initial import of Rust implementation of Codex CLI in codex-rs/ (#629)
As stated in `codex-rs/README.md`:
Today, Codex CLI is written in TypeScript and requires Node.js 22+ to
run it. For a number of users, this runtime requirement inhibits
adoption: they would be better served by a standalone executable. As
maintainers, we want Codex to run efficiently in a wide range of
environments with minimal overhead. We also want to take advantage of
operating system-specific APIs to provide better sandboxing, where
possible.
To that end, we are moving forward with a Rust implementation of Codex
CLI contained in this folder, which has the following benefits:
- The CLI compiles to small, standalone, platform-specific binaries.
- Can make direct, native calls to
[seccomp](https://man7.org/linux/man-pages/man2/seccomp.2.html) and
[landlock](https://man7.org/linux/man-pages/man7/landlock.7.html) in
order to support sandboxing on Linux.
- No runtime garbage collection, resulting in lower memory consumption
and better, more predictable performance.
Currently, the Rust implementation is materially behind the TypeScript
implementation in functionality, so continue to use the TypeScript
implmentation for the time being. We will publish native executables via
GitHub Releases as soon as we feel the Rust version is usable.
2025-04-24 13:31:40 -07:00
|
|
|
"cli",
|
2026-03-11 22:06:59 -07:00
|
|
|
"connectors",
|
2026-02-11 10:02:49 -08:00
|
|
|
"config",
|
2026-02-10 17:03:46 -08:00
|
|
|
"shell-command",
|
2026-02-23 09:28:17 -08:00
|
|
|
"shell-escalation",
|
2026-02-21 00:34:08 -08:00
|
|
|
"skills",
|
feat: initial import of Rust implementation of Codex CLI in codex-rs/ (#629)
As stated in `codex-rs/README.md`:
Today, Codex CLI is written in TypeScript and requires Node.js 22+ to
run it. For a number of users, this runtime requirement inhibits
adoption: they would be better served by a standalone executable. As
maintainers, we want Codex to run efficiently in a wide range of
environments with minimal overhead. We also want to take advantage of
operating system-specific APIs to provide better sandboxing, where
possible.
To that end, we are moving forward with a Rust implementation of Codex
CLI contained in this folder, which has the following benefits:
- The CLI compiles to small, standalone, platform-specific binaries.
- Can make direct, native calls to
[seccomp](https://man7.org/linux/man-pages/man2/seccomp.2.html) and
[landlock](https://man7.org/linux/man-pages/man7/landlock.7.html) in
order to support sandboxing on Linux.
- No runtime garbage collection, resulting in lower memory consumption
and better, more predictable performance.
Currently, the Rust implementation is materially behind the TypeScript
implementation in functionality, so continue to use the TypeScript
implmentation for the time being. We will publish native executables via
GitHub Releases as soon as we feel the Rust version is usable.
2025-04-24 13:31:40 -07:00
|
|
|
"core",
|
2026-02-10 13:42:17 +00:00
|
|
|
"hooks",
|
2026-02-03 00:14:39 -08:00
|
|
|
"secrets",
|
feat: initial import of Rust implementation of Codex CLI in codex-rs/ (#629)
As stated in `codex-rs/README.md`:
Today, Codex CLI is written in TypeScript and requires Node.js 22+ to
run it. For a number of users, this runtime requirement inhibits
adoption: they would be better served by a standalone executable. As
maintainers, we want Codex to run efficiently in a wide range of
environments with minimal overhead. We also want to take advantage of
operating system-specific APIs to provide better sandboxing, where
possible.
To that end, we are moving forward with a Rust implementation of Codex
CLI contained in this folder, which has the following benefits:
- The CLI compiles to small, standalone, platform-specific binaries.
- Can make direct, native calls to
[seccomp](https://man7.org/linux/man-pages/man2/seccomp.2.html) and
[landlock](https://man7.org/linux/man-pages/man7/landlock.7.html) in
order to support sandboxing on Linux.
- No runtime garbage collection, resulting in lower memory consumption
and better, more predictable performance.
Currently, the Rust implementation is materially behind the TypeScript
implementation in functionality, so continue to use the TypeScript
implmentation for the time being. We will publish native executables via
GitHub Releases as soon as we feel the Rust version is usable.
2025-04-24 13:31:40 -07:00
|
|
|
"exec",
|
2026-03-18 17:30:05 -07:00
|
|
|
"exec-server",
|
2025-04-24 17:14:47 -07:00
|
|
|
"execpolicy",
|
2025-11-19 19:14:10 -08:00
|
|
|
"execpolicy-legacy",
|
2025-10-27 12:10:11 -07:00
|
|
|
"keyring-store",
|
2025-06-25 13:29:03 -07:00
|
|
|
"file-search",
|
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.
2025-05-23 11:37:07 -07:00
|
|
|
"linux-sandbox",
|
2025-11-17 14:49:09 -05:00
|
|
|
"lmstudio",
|
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
2025-06-04 08:44:17 -07:00
|
|
|
"login",
|
2025-05-02 17:25:58 -07:00
|
|
|
"mcp-server",
|
2026-01-23 20:47:09 -05:00
|
|
|
"network-proxy",
|
2025-08-05 11:31:11 -07:00
|
|
|
"ollama",
|
2025-09-28 14:35:14 -07:00
|
|
|
"process-hardening",
|
2025-08-15 12:44:40 -07:00
|
|
|
"protocol",
|
2025-09-26 10:13:37 -07:00
|
|
|
"rmcp-client",
|
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
2025-09-26 08:19:00 -07:00
|
|
|
"responses-api-proxy",
|
2025-10-19 21:12:45 -07:00
|
|
|
"stdio-to-uds",
|
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>
2025-09-29 19:30:55 +01:00
|
|
|
"otel",
|
feat: initial import of Rust implementation of Codex CLI in codex-rs/ (#629)
As stated in `codex-rs/README.md`:
Today, Codex CLI is written in TypeScript and requires Node.js 22+ to
run it. For a number of users, this runtime requirement inhibits
adoption: they would be better served by a standalone executable. As
maintainers, we want Codex to run efficiently in a wide range of
environments with minimal overhead. We also want to take advantage of
operating system-specific APIs to provide better sandboxing, where
possible.
To that end, we are moving forward with a Rust implementation of Codex
CLI contained in this folder, which has the following benefits:
- The CLI compiles to small, standalone, platform-specific binaries.
- Can make direct, native calls to
[seccomp](https://man7.org/linux/man-pages/man2/seccomp.2.html) and
[landlock](https://man7.org/linux/man-pages/man7/landlock.7.html) in
order to support sandboxing on Linux.
- No runtime garbage collection, resulting in lower memory consumption
and better, more predictable performance.
Currently, the Rust implementation is materially behind the TypeScript
implementation in functionality, so continue to use the TypeScript
implmentation for the time being. We will publish native executables via
GitHub Releases as soon as we feel the Rust version is usable.
2025-04-24 13:31:40 -07:00
|
|
|
"tui",
|
2026-03-16 10:49:19 -06:00
|
|
|
"tui_app_server",
|
2026-03-20 12:08:25 -07:00
|
|
|
"v8-poc",
|
fix: introduce AbsolutePathBuf and resolve relative paths in config.toml (#7796)
This PR attempts to solve two problems by introducing a
`AbsolutePathBuf` type with a special deserializer:
- `AbsolutePathBuf` attempts to be a generally useful abstraction, as it
ensures, by constructing, that it represents a value that is an
absolute, normalized path, which is a stronger guarantee than an
arbitrary `PathBuf`.
- Values in `config.toml` that can be either an absolute or relative
path should be resolved against the folder containing the `config.toml`
in the relative path case. This PR makes this easy to support: the main
cost is ensuring `AbsolutePathBufGuard` is used inside
`deserialize_config_toml_with_base()`.
While `AbsolutePathBufGuard` may seem slightly distasteful because it
relies on thread-local storage, this seems much cleaner to me than using
than my various experiments with
https://docs.rs/serde/latest/serde/de/trait.DeserializeSeed.html.
Further, since the `deserialize()` method from the `Deserialize` trait
is not async, we do not really have to worry about the deserialization
work being spread across multiple threads in a way that would interfere
with `AbsolutePathBufGuard`.
To start, this PR introduces the use of `AbsolutePathBuf` in
`OtelTlsConfig`. Note how this simplifies `otel_provider.rs` because it
no longer requires `settings.codex_home` to be threaded through.
Furthermore, this sets us up better for a world where multiple
`config.toml` files from different folders could be loaded and then
merged together, as the absolutifying of the paths must be done against
the correct parent folder.
2025-12-09 17:37:52 -08:00
|
|
|
"utils/absolute-path",
|
2025-12-23 19:29:32 -08:00
|
|
|
"utils/cargo-bin",
|
2025-10-29 12:11:44 +00:00
|
|
|
"utils/git",
|
2025-10-27 16:58:10 +00:00
|
|
|
"utils/cache",
|
|
|
|
|
"utils/image",
|
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`.
2025-09-30 00:06:18 -07:00
|
|
|
"utils/json-to-toml",
|
2026-01-30 15:46:33 -08:00
|
|
|
"utils/home-dir",
|
2025-10-20 20:57:37 +01:00
|
|
|
"utils/pty",
|
2025-10-27 16:58:10 +00:00
|
|
|
"utils/readiness",
|
2026-02-10 01:04:31 -08:00
|
|
|
"utils/rustls-provider",
|
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
2025-10-03 13:21:06 +01:00
|
|
|
"utils/string",
|
2026-02-11 04:59:24 -08:00
|
|
|
"utils/cli",
|
|
|
|
|
"utils/elapsed",
|
|
|
|
|
"utils/sandbox-summary",
|
2026-02-13 18:31:39 +00:00
|
|
|
"utils/sleep-inhibitor",
|
2026-02-11 04:59:24 -08:00
|
|
|
"utils/approval-presets",
|
|
|
|
|
"utils/oss",
|
|
|
|
|
"utils/fuzzy-match",
|
2026-02-25 13:27:58 +00:00
|
|
|
"utils/stream-parser",
|
2025-11-25 18:06:12 +00:00
|
|
|
"codex-client",
|
|
|
|
|
"codex-api",
|
2026-01-28 15:29:14 +01:00
|
|
|
"state",
|
2026-03-19 14:08:04 -07:00
|
|
|
"terminal-detection",
|
2026-02-02 12:06:50 +01:00
|
|
|
"codex-experimental-api-macros",
|
2026-02-25 13:19:21 +00:00
|
|
|
"test-macros",
|
2026-03-04 20:22:34 +00:00
|
|
|
"package-manager",
|
|
|
|
|
"artifacts",
|
feat: initial import of Rust implementation of Codex CLI in codex-rs/ (#629)
As stated in `codex-rs/README.md`:
Today, Codex CLI is written in TypeScript and requires Node.js 22+ to
run it. For a number of users, this runtime requirement inhibits
adoption: they would be better served by a standalone executable. As
maintainers, we want Codex to run efficiently in a wide range of
environments with minimal overhead. We also want to take advantage of
operating system-specific APIs to provide better sandboxing, where
possible.
To that end, we are moving forward with a Rust implementation of Codex
CLI contained in this folder, which has the following benefits:
- The CLI compiles to small, standalone, platform-specific binaries.
- Can make direct, native calls to
[seccomp](https://man7.org/linux/man-pages/man2/seccomp.2.html) and
[landlock](https://man7.org/linux/man-pages/man7/landlock.7.html) in
order to support sandboxing on Linux.
- No runtime garbage collection, resulting in lower memory consumption
and better, more predictable performance.
Currently, the Rust implementation is materially behind the TypeScript
implementation in functionality, so continue to use the TypeScript
implmentation for the time being. We will publish native executables via
GitHub Releases as soon as we feel the Rust version is usable.
2025-04-24 13:31:40 -07:00
|
|
|
]
|
2025-07-30 18:37:00 -07:00
|
|
|
resolver = "2"
|
2025-04-29 16:38:47 -07:00
|
|
|
|
|
|
|
|
[workspace.package]
|
2025-04-30 12:39:03 -07:00
|
|
|
version = "0.0.0"
|
2025-05-07 08:37:48 -07:00
|
|
|
# Track the edition for all workspace crates in one place. Individual
|
|
|
|
|
# crates can still override this value, but keeping it here means new
|
|
|
|
|
# crates created with `cargo new -w ...` automatically inherit the 2024
|
|
|
|
|
# edition.
|
|
|
|
|
edition = "2024"
|
2025-11-24 12:22:18 -08:00
|
|
|
license = "Apache-2.0"
|
2025-04-29 16:38:47 -07:00
|
|
|
|
2025-09-22 18:47:01 +02:00
|
|
|
[workspace.dependencies]
|
|
|
|
|
# Internal
|
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`.
2025-09-30 00:06:18 -07:00
|
|
|
app_test_support = { path = "app-server/tests/common" }
|
2025-09-22 18:47:01 +02:00
|
|
|
codex-ansi-escape = { path = "ansi-escape" }
|
2025-12-01 14:01:50 -08:00
|
|
|
codex-api = { path = "codex-api" }
|
2026-03-04 20:22:34 +00:00
|
|
|
codex-artifacts = { path = "artifacts" }
|
Code mode on v8 (#15276)
Moves Code Mode to a new crate with no dependencies on codex. This
create encodes the code mode semantics that we want for lifetime,
mounting, tool calling.
The model-facing surface is mostly unchanged. `exec` still runs raw
JavaScript, `wait` still resumes or terminates a `cell_id`, nested tools
are still available through `tools.*`, and helpers like `text`, `image`,
`store`, `load`, `notify`, `yield_control`, and `exit` still exist.
The major change is underneath that surface:
- Old code mode was an external Node runtime.
- New code mode is an in-process V8 runtime embedded directly in Rust.
- Old code mode managed cells inside a long-lived Node runner process.
- New code mode manages cells in Rust, with one V8 runtime thread per
active `exec`.
- Old code mode used JSON protocol messages over child stdin/stdout plus
Node worker-thread messages.
- New code mode uses Rust channels and direct V8 callbacks/events.
This PR also fixes the two migration regressions that fell out of that
substrate change:
- `wait { terminate: true }` now waits for the V8 runtime to actually
stop before reporting termination.
- synchronous top-level `exit()` now succeeds again instead of surfacing
as a script error.
---
- `core/src/tools/code_mode/*` is now mostly an adapter layer for the
public `exec` / `wait` tools.
- `code-mode/src/service.rs` owns cell sessions and async control flow
in Rust.
- `code-mode/src/runtime/*.rs` owns the embedded V8 isolate and
JavaScript execution.
- each `exec` spawns a dedicated runtime thread plus a Rust
session-control task.
- helper globals are installed directly into the V8 context instead of
being injected through a source prelude.
- helper modules like `tools.js` and `@openai/code_mode` are synthesized
through V8 module resolution callbacks in Rust.
---
Also added a benchmark for showing the speed of init and use of a code
mode env:
```
$ cargo bench -p codex-code-mode --bench exec_overhead -- --samples 30 --warm-iterations 25 --tool-counts 0,32,128
Finished [`bench` profile [optimized]](https://doc.rust-lang.org/cargo/reference/profiles.html#default-profiles) target(s) in 0.18s
Running benches/exec_overhead.rs (target/release/deps/exec_overhead-008c440d800545ae)
exec_overhead: samples=30, warm_iterations=25, tool_counts=[0, 32, 128]
scenario tools samples warmups iters mean/exec p95/exec rssΔ p50 rssΔ max
cold_exec 0 30 0 1 1.13ms 1.20ms 8.05MiB 8.06MiB
warm_exec 0 30 1 25 473.43us 512.49us 912.00KiB 1.33MiB
cold_exec 32 30 0 1 1.03ms 1.15ms 8.08MiB 8.11MiB
warm_exec 32 30 1 25 509.73us 545.76us 960.00KiB 1.30MiB
cold_exec 128 30 0 1 1.14ms 1.19ms 8.30MiB 8.34MiB
warm_exec 128 30 1 25 575.08us 591.03us 736.00KiB 864.00KiB
memory uses a fresh-process max RSS delta for each scenario
```
---------
Co-authored-by: Codex <noreply@openai.com>
2026-03-20 23:36:58 -07:00
|
|
|
codex-code-mode = { path = "code-mode" }
|
2026-03-04 20:22:34 +00:00
|
|
|
codex-package-manager = { path = "package-manager" }
|
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`.
2025-09-30 00:06:18 -07:00
|
|
|
codex-app-server = { path = "app-server" }
|
2026-03-08 18:43:55 -06:00
|
|
|
codex-app-server-client = { path = "app-server-client" }
|
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.
2025-09-30 19:16:26 -07:00
|
|
|
codex-app-server-protocol = { path = "app-server-protocol" }
|
chore: add `codex debug app-server` tooling (#10367)
codex debug app-server <user message> forwards the message through
codex-app-server-test-client’s send_message_v2 library entry point,
using std::env::current_exe() to resolve the codex binary.
for how it looks like, see:
```
celia@com-92114 codex-rs % cargo build -p codex-cli && target/debug/codex debug app-server --help
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.34s
Tooling: helps debug the app server
Usage: codex debug app-server [OPTIONS] <COMMAND>
Commands:
send-message-v2
help Print this message or the help of the given subcommand(s)
````
and
```
celia@com-92114 codex-rs % cargo build -p codex-cli && target/debug/codex debug app-server send-message-v2 "hello world"
Compiling codex-cli v0.0.0 (/Users/celia/code/codex/codex-rs/cli)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.38s
> {
> "method": "initialize",
> "id": "f8ba9f60-3a49-4ea9-81d6-4ab6853e3954",
> "params": {
> "clientInfo": {
> "name": "codex-toy-app-server",
> "title": "Codex Toy App Server",
> "version": "0.0.0"
> },
> "capabilities": {
> "experimentalApi": true
> }
> }
> }
< {
< "id": "f8ba9f60-3a49-4ea9-81d6-4ab6853e3954",
< "result": {
< "userAgent": "codex-toy-app-server/0.0.0 (Mac OS 26.2.0; arm64) vscode/2.4.27 (codex-toy-app-server; 0.0.0)"
< }
< }
< initialize response: InitializeResponse { user_agent: "codex-toy-app-server/0.0.0 (Mac OS 26.2.0; arm64) vscode/2.4.27 (codex-toy-app-server; 0.0.0)" }
> {
> "method": "thread/start",
> "id": "203f1630-beee-4e60-b17b-9eff16b1638b",
> "params": {
> "model": null,
> "modelProvider": null,
> "cwd": null,
> "approvalPolicy": null,
> "sandbox": null,
> "config": null,
> "baseInstructions": null,
> "developerInstructions": null,
> "personality": null,
> "ephemeral": null,
> "dynamicTools": null,
> "mockExperimentalField": null,
> "experimentalRawEvents": false
> }
> }
...
```
2026-02-03 15:17:34 -08:00
|
|
|
codex-app-server-test-client = { path = "app-server-test-client" }
|
2025-09-22 18:47:01 +02:00
|
|
|
codex-apply-patch = { path = "apply-patch" }
|
|
|
|
|
codex-arg0 = { path = "arg0" }
|
2025-10-19 21:12:45 -07:00
|
|
|
codex-async-utils = { path = "async-utils" }
|
2025-10-20 14:11:54 -07:00
|
|
|
codex-backend-client = { path = "backend-client" }
|
2025-09-22 18:47:01 +02:00
|
|
|
codex-chatgpt = { path = "chatgpt" }
|
2026-02-11 10:02:49 -08:00
|
|
|
codex-cli = { path = "cli" }
|
2025-12-01 14:01:50 -08:00
|
|
|
codex-client = { path = "codex-client" }
|
2026-02-11 10:02:49 -08:00
|
|
|
codex-cloud-requirements = { path = "cloud-requirements" }
|
2026-03-11 22:06:59 -07:00
|
|
|
codex-connectors = { path = "connectors" }
|
2026-02-11 10:02:49 -08:00
|
|
|
codex-config = { path = "config" }
|
2025-09-22 18:47:01 +02:00
|
|
|
codex-core = { path = "core" }
|
|
|
|
|
codex-exec = { path = "exec" }
|
2026-03-19 08:31:14 -07:00
|
|
|
codex-exec-server = { path = "exec-server" }
|
2025-11-19 19:14:10 -08:00
|
|
|
codex-execpolicy = { path = "execpolicy" }
|
2026-02-02 12:06:50 +01:00
|
|
|
codex-experimental-api-macros = { path = "codex-experimental-api-macros" }
|
2025-10-16 21:03:23 -07:00
|
|
|
codex-feedback = { path = "feedback" }
|
2026-03-19 20:12:07 -07:00
|
|
|
codex-features = { path = "features" }
|
2025-09-22 18:47:01 +02:00
|
|
|
codex-file-search = { path = "file-search" }
|
2025-10-29 12:11:44 +00:00
|
|
|
codex-git = { path = "utils/git" }
|
2026-02-11 10:02:49 -08:00
|
|
|
codex-hooks = { path = "hooks" }
|
2025-10-27 12:10:11 -07:00
|
|
|
codex-keyring-store = { path = "keyring-store" }
|
2025-09-22 18:47:01 +02:00
|
|
|
codex-linux-sandbox = { path = "linux-sandbox" }
|
2025-11-17 14:49:09 -05:00
|
|
|
codex-lmstudio = { path = "lmstudio" }
|
2025-09-22 18:47:01 +02:00
|
|
|
codex-login = { path = "login" }
|
|
|
|
|
codex-mcp-server = { path = "mcp-server" }
|
2026-02-08 19:32:17 -08:00
|
|
|
codex-network-proxy = { path = "network-proxy" }
|
2025-09-22 18:47:01 +02:00
|
|
|
codex-ollama = { path = "ollama" }
|
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`.
2025-09-30 00:06:18 -07:00
|
|
|
codex-otel = { path = "otel" }
|
2025-09-28 14:35:14 -07:00
|
|
|
codex-process-hardening = { path = "process-hardening" }
|
2025-09-22 18:47:01 +02:00
|
|
|
codex-protocol = { path = "protocol" }
|
2025-09-30 03:10:33 -07:00
|
|
|
codex-responses-api-proxy = { path = "responses-api-proxy" }
|
2025-09-28 14:35:14 -07:00
|
|
|
codex-rmcp-client = { path = "rmcp-client" }
|
2026-02-11 10:02:49 -08:00
|
|
|
codex-secrets = { path = "secrets" }
|
|
|
|
|
codex-shell-command = { path = "shell-command" }
|
2026-02-24 10:31:08 -08:00
|
|
|
codex-shell-escalation = { path = "shell-escalation" }
|
2026-02-21 00:34:08 -08:00
|
|
|
codex-skills = { path = "skills" }
|
2026-01-28 15:29:14 +01:00
|
|
|
codex-state = { path = "state" }
|
2025-10-19 21:12:45 -07:00
|
|
|
codex-stdio-to-uds = { path = "stdio-to-uds" }
|
2026-02-26 08:39:24 -08:00
|
|
|
codex-test-macros = { path = "test-macros" }
|
2026-03-19 14:08:04 -07:00
|
|
|
codex-terminal-detection = { path = "terminal-detection" }
|
2025-09-22 18:47:01 +02:00
|
|
|
codex-tui = { path = "tui" }
|
2026-03-16 10:49:19 -06:00
|
|
|
codex-tui-app-server = { path = "tui_app_server" }
|
2026-03-20 12:08:25 -07:00
|
|
|
codex-v8-poc = { path = "v8-poc" }
|
fix: introduce AbsolutePathBuf and resolve relative paths in config.toml (#7796)
This PR attempts to solve two problems by introducing a
`AbsolutePathBuf` type with a special deserializer:
- `AbsolutePathBuf` attempts to be a generally useful abstraction, as it
ensures, by constructing, that it represents a value that is an
absolute, normalized path, which is a stronger guarantee than an
arbitrary `PathBuf`.
- Values in `config.toml` that can be either an absolute or relative
path should be resolved against the folder containing the `config.toml`
in the relative path case. This PR makes this easy to support: the main
cost is ensuring `AbsolutePathBufGuard` is used inside
`deserialize_config_toml_with_base()`.
While `AbsolutePathBufGuard` may seem slightly distasteful because it
relies on thread-local storage, this seems much cleaner to me than using
than my various experiments with
https://docs.rs/serde/latest/serde/de/trait.DeserializeSeed.html.
Further, since the `deserialize()` method from the `Deserialize` trait
is not async, we do not really have to worry about the deserialization
work being spread across multiple threads in a way that would interfere
with `AbsolutePathBufGuard`.
To start, this PR introduces the use of `AbsolutePathBuf` in
`OtelTlsConfig`. Note how this simplifies `otel_provider.rs` because it
no longer requires `settings.codex_home` to be threaded through.
Furthermore, this sets us up better for a world where multiple
`config.toml` files from different folders could be loaded and then
merged together, as the absolutifying of the paths must be done against
the correct parent folder.
2025-12-09 17:37:52 -08:00
|
|
|
codex-utils-absolute-path = { path = "utils/absolute-path" }
|
2026-02-11 10:02:49 -08:00
|
|
|
codex-utils-approval-presets = { path = "utils/approval-presets" }
|
2025-10-27 16:58:10 +00:00
|
|
|
codex-utils-cache = { path = "utils/cache" }
|
2025-12-23 19:29:32 -08:00
|
|
|
codex-utils-cargo-bin = { path = "utils/cargo-bin" }
|
2026-02-11 10:02:49 -08:00
|
|
|
codex-utils-cli = { path = "utils/cli" }
|
|
|
|
|
codex-utils-elapsed = { path = "utils/elapsed" }
|
|
|
|
|
codex-utils-fuzzy-match = { path = "utils/fuzzy-match" }
|
|
|
|
|
codex-utils-home-dir = { path = "utils/home-dir" }
|
2025-10-27 16:58:10 +00:00
|
|
|
codex-utils-image = { path = "utils/image" }
|
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`.
2025-09-30 00:06:18 -07:00
|
|
|
codex-utils-json-to-toml = { path = "utils/json-to-toml" }
|
2026-02-11 10:02:49 -08:00
|
|
|
codex-utils-oss = { path = "utils/oss" }
|
2025-10-20 20:57:37 +01:00
|
|
|
codex-utils-pty = { path = "utils/pty" }
|
2025-10-20 14:52:37 -07:00
|
|
|
codex-utils-readiness = { path = "utils/readiness" }
|
2026-02-10 01:04:31 -08:00
|
|
|
codex-utils-rustls-provider = { path = "utils/rustls-provider" }
|
2026-02-11 04:59:24 -08:00
|
|
|
codex-utils-sandbox-summary = { path = "utils/sandbox-summary" }
|
2026-02-13 18:31:39 +00:00
|
|
|
codex-utils-sleep-inhibitor = { path = "utils/sleep-inhibitor" }
|
2026-02-25 13:27:58 +00:00
|
|
|
codex-utils-stream-parser = { path = "utils/stream-parser" }
|
2026-02-26 08:39:24 -08:00
|
|
|
codex-utils-string = { path = "utils/string" }
|
2025-11-06 10:44:42 -08:00
|
|
|
codex-windows-sandbox = { path = "windows-sandbox-rs" }
|
2025-09-22 18:47:01 +02:00
|
|
|
core_test_support = { path = "core/tests/common" }
|
|
|
|
|
mcp_test_support = { path = "mcp-server/tests/common" }
|
|
|
|
|
|
|
|
|
|
# External
|
2026-02-03 00:14:39 -08:00
|
|
|
age = "0.11.1"
|
2025-09-22 18:47:01 +02:00
|
|
|
allocative = "0.3.3"
|
|
|
|
|
ansi-to-tui = "7.0.0"
|
|
|
|
|
anyhow = "1"
|
2025-11-10 19:35:30 -03:00
|
|
|
arboard = { version = "3", features = ["wayland-data-control"] }
|
2026-02-25 18:06:17 +00:00
|
|
|
askama = "0.15.4"
|
2025-09-22 18:47:01 +02:00
|
|
|
assert_cmd = "2"
|
2025-10-16 21:03:23 -07:00
|
|
|
assert_matches = "1.5.0"
|
2025-09-22 18:47:01 +02:00
|
|
|
async-channel = "2.3.1"
|
|
|
|
|
async-stream = "0.3.6"
|
2025-09-23 17:27:20 +01:00
|
|
|
async-trait = "0.1.89"
|
2025-10-03 10:43:12 -07:00
|
|
|
axum = { version = "0.8", default-features = false }
|
2025-09-22 18:47:01 +02:00
|
|
|
base64 = "0.22.1"
|
2026-02-09 12:53:50 -08:00
|
|
|
bm25 = "2.3.2"
|
2025-09-22 18:47:01 +02:00
|
|
|
bytes = "1.10.1"
|
2025-11-21 03:04:11 +08:00
|
|
|
chardetng = "0.1.17"
|
2026-01-19 06:43:34 +00:00
|
|
|
chrono = "0.4.43"
|
2025-09-22 18:47:01 +02:00
|
|
|
clap = "4"
|
|
|
|
|
clap_complete = "4"
|
|
|
|
|
color-eyre = "0.6.3"
|
2026-01-28 10:54:43 -08:00
|
|
|
crossbeam-channel = "0.5.15"
|
2026-02-11 10:02:49 -08:00
|
|
|
crossterm = "0.28.1"
|
2026-02-26 08:39:24 -08:00
|
|
|
csv = "1.3.1"
|
2026-01-18 22:37:11 -08:00
|
|
|
ctor = "0.6.3"
|
2025-09-22 18:47:01 +02:00
|
|
|
derive_more = "2"
|
|
|
|
|
diffy = "0.4.2"
|
|
|
|
|
dirs = "6"
|
|
|
|
|
dotenvy = "0.15.7"
|
2025-10-01 14:33:19 -07:00
|
|
|
dunce = "1.0.4"
|
feat: declare server capability in shell-tool-mcp (#7112)
This introduces a new feature to Codex when it operates as an MCP
_client_ where if an MCP _server_ replies that it has an entry named
`"codex/sandbox-state"` in its _server capabilities_, then Codex will
send it an MCP notification with the following structure:
```json
{
"method": "codex/sandbox-state/update",
"params": {
"sandboxPolicy": {
"type": "workspace-write",
"network-access": false,
"exclude-tmpdir-env-var": false
"exclude-slash-tmp": false
},
"codexLinuxSandboxExe": null,
"sandboxCwd": "/Users/mbolin/code/codex2"
}
}
```
or with whatever values are appropriate for the initial `sandboxPolicy`.
**NOTE:** Codex _should_ continue to send the MCP server notifications
of the same format if these things change over the lifetime of the
thread, but that isn't wired up yet.
The result is that `shell-tool-mcp` can consume these values so that
when it calls `codex_core::exec::process_exec_tool_call()` in
`codex-rs/exec-server/src/posix/escalate_server.rs`, it is now sure to
call it with the correct values (whereas previously we relied on
hardcoded values).
While I would argue this is a supported use case within the MCP
protocol, the `rmcp` crate that we are using today does not support
custom notifications. As such, I had to patch it and I submitted it for
review, so hopefully it will be accepted in some form:
https://github.com/modelcontextprotocol/rust-sdk/pull/556
To test out this change from end-to-end:
- I ran `cargo build` in `~/code/codex2/codex-rs/exec-server`
- I built the fork of Bash in `~/code/bash/bash`
- I added the following to my `~/.codex/config.toml`:
```toml
# Use with `codex --disable shell_tool`.
[mcp_servers.execshell]
args = ["--bash", "/Users/mbolin/code/bash/bash"]
command = "/Users/mbolin/code/codex2/codex-rs/target/debug/codex-exec-mcp-server"
```
- From `~/code/codex2/codex-rs`, I ran `just codex --disable shell_tool`
- When the TUI started up, I verified that the sandbox mode is
`workspace-write`
- I ran `/mcp` to verify that the shell tool from the MCP is there:
<img width="1387" height="1400" alt="image"
src="https://github.com/user-attachments/assets/1a8addcc-5005-4e16-b59f-95cfd06fd4ab"
/>
- Then I asked it:
> what is the output of `gh issue list`
because this should be auto-approved with our existing dummy policy:
https://github.com/openai/codex/blob/af63e6eccc35783f1bf4dca3c61adb090efb6b8a/codex-rs/exec-server/src/posix.rs#L157-L164
And it worked:
<img width="1387" height="1400" alt="image"
src="https://github.com/user-attachments/assets/7568d2f7-80da-4d68-86d0-c265a6f5e6c1"
/>
2025-11-21 16:11:01 -08:00
|
|
|
encoding_rs = "0.8.35"
|
2026-03-05 11:57:13 +00:00
|
|
|
fd-lock = "4.0.4"
|
2025-09-22 18:47:01 +02:00
|
|
|
env-flags = "0.1.1"
|
2026-02-17 12:08:28 -08:00
|
|
|
env_logger = "0.11.9"
|
2025-09-28 14:35:14 -07:00
|
|
|
eventsource-stream = "0.2.3"
|
2026-03-04 20:22:34 +00:00
|
|
|
flate2 = "1.1.4"
|
2025-10-03 10:43:12 -07:00
|
|
|
futures = { version = "0.3", default-features = false }
|
2026-02-25 09:54:45 -05:00
|
|
|
gethostname = "1.1.0"
|
2026-02-26 08:39:24 -08:00
|
|
|
globset = "0.4"
|
2025-10-24 09:47:52 -07:00
|
|
|
http = "1.3.1"
|
2025-10-29 20:46:45 +00:00
|
|
|
icu_decimal = "2.1"
|
|
|
|
|
icu_locale_core = "2.1"
|
2025-11-12 22:24:36 -08:00
|
|
|
icu_provider = { version = "2.1", features = ["sync"] }
|
2025-09-22 18:47:01 +02:00
|
|
|
ignore = "0.4.23"
|
2025-11-30 20:50:51 -08:00
|
|
|
image = { version = "^0.25.9", default-features = false }
|
2026-02-26 15:17:35 -08:00
|
|
|
iana-time-zone = "0.1.64"
|
2025-12-17 18:48:28 -08:00
|
|
|
include_dir = "0.7.4"
|
chore(deps): bump indexmap from 2.10.0 to 2.11.4 in /codex-rs (#4804)
Bumps [indexmap](https://github.com/indexmap-rs/indexmap) from 2.10.0 to
2.11.4.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/indexmap-rs/indexmap/blob/main/RELEASES.md">indexmap's
changelog</a>.</em></p>
<blockquote>
<h2>2.11.4 (2025-09-18)</h2>
<ul>
<li>Updated the <code>hashbrown</code> dependency to a range allowing
0.15 or 0.16.</li>
</ul>
<h2>2.11.3 (2025-09-15)</h2>
<ul>
<li>Make the minimum <code>serde</code> version only apply when
"serde" is enabled.</li>
</ul>
<h2>2.11.2 (2025-09-15)</h2>
<ul>
<li>Switched the "serde" feature to depend on
<code>serde_core</code>, improving build
parallelism in cases where other dependents have enabled
"serde/derive".</li>
</ul>
<h2>2.11.1 (2025-09-08)</h2>
<ul>
<li>Added a <code>get_key_value_mut</code> method to
<code>IndexMap</code>.</li>
<li>Removed the unnecessary <code>Ord</code> bound on
<code>insert_sorted_by</code> methods.</li>
</ul>
<h2>2.11.0 (2025-08-22)</h2>
<ul>
<li>Added <code>insert_sorted_by</code> and
<code>insert_sorted_by_key</code> methods to <code>IndexMap</code>,
<code>IndexSet</code>, and <code>VacantEntry</code>, like customizable
versions of <code>insert_sorted</code>.</li>
<li>Added <code>is_sorted</code>, <code>is_sorted_by</code>, and
<code>is_sorted_by_key</code> methods to
<code>IndexMap</code> and <code>IndexSet</code>, as well as their
<code>Slice</code> counterparts.</li>
<li>Added <code>sort_by_key</code> and <code>sort_unstable_by_key</code>
methods to <code>IndexMap</code> and
<code>IndexSet</code>, as well as parallel counterparts.</li>
<li>Added <code>replace_index</code> methods to <code>IndexMap</code>,
<code>IndexSet</code>, and <code>VacantEntry</code>
to replace the key (or set value) at a given index.</li>
<li>Added optional <code>sval</code> serialization support.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/indexmap-rs/indexmap/commit/03f9e58626ad7ef811b1522097bced2400c18b1a"><code>03f9e58</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/418">#418</a>
from a1phyr/hashbrown_0.16</li>
<li><a
href="https://github.com/indexmap-rs/indexmap/commit/ee6080d480eea3b738757c6bff1bb21b440f3849"><code>ee6080d</code></a>
Release 2.11.4</li>
<li><a
href="https://github.com/indexmap-rs/indexmap/commit/a7da8f181e81f8a37bc46936bf2d1d6db14edddc"><code>a7da8f1</code></a>
Use a range for hashbrown</li>
<li><a
href="https://github.com/indexmap-rs/indexmap/commit/0cd5aefb4434fb495cb87ba5de50870d331558fc"><code>0cd5aef</code></a>
Update <code>hashbrown</code> to 0.16</li>
<li><a
href="https://github.com/indexmap-rs/indexmap/commit/fd5c819daf8c3c62919ec0bbc777a571ee20ae5a"><code>fd5c819</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/417">#417</a>
from cuviper/release-2.11.3</li>
<li><a
href="https://github.com/indexmap-rs/indexmap/commit/9321145e1f517f31969c0d9ab5a5171cc23c3daf"><code>9321145</code></a>
Release 2.11.3</li>
<li><a
href="https://github.com/indexmap-rs/indexmap/commit/7b485688c299ed840d900b5a33aed33a1924a7c9"><code>7b48568</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/416">#416</a>
from cuviper/release-2.11.2</li>
<li><a
href="https://github.com/indexmap-rs/indexmap/commit/49ce7fa4716e24cf9380653a40d88b5186f2f555"><code>49ce7fa</code></a>
Release 2.11.2</li>
<li><a
href="https://github.com/indexmap-rs/indexmap/commit/58fd834804415879eb9be862291eba03e945e32a"><code>58fd834</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/414">#414</a>
from DaniPopes/serde_core</li>
<li><a
href="https://github.com/indexmap-rs/indexmap/commit/5dc1d6ab3105739ae61039f422e5246f0eee4f64"><code>5dc1d6a</code></a>
Depend on <code>serde_core</code> instead of <code>serde</code></li>
<li>Additional commits viewable in <a
href="https://github.com/indexmap-rs/indexmap/compare/2.10.0...2.11.4">compare
view</a></li>
</ul>
</details>
<br />
[](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>
Co-authored-by: Eric Traut <etraut@openai.com>
2025-10-31 10:15:52 -07:00
|
|
|
indexmap = "2.12.0"
|
2026-02-09 21:33:31 -08:00
|
|
|
insta = "1.46.3"
|
2026-02-02 12:06:50 +01:00
|
|
|
inventory = "0.3.19"
|
2025-09-22 18:47:01 +02:00
|
|
|
itertools = "0.14.0"
|
2025-11-16 23:07:34 -06:00
|
|
|
keyring = { version = "3.6", default-features = false }
|
2025-12-22 08:35:23 -07:00
|
|
|
landlock = "0.4.4"
|
2025-09-22 18:47:01 +02:00
|
|
|
lazy_static = "1"
|
chore(deps): bump libc from 0.2.180 to 0.2.182 in /codex-rs (#12528)
Bumps [libc](https://github.com/rust-lang/libc) from 0.2.180 to 0.2.182.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/rust-lang/libc/releases">libc's
releases</a>.</em></p>
<blockquote>
<h2>0.2.182</h2>
<h3>Added</h3>
<ul>
<li>Android, Linux: Add <code>tgkill</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4970">#4970</a>)</li>
<li>Redox: Add <code>RENAME_NOREPLACE</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4968">#4968</a>)</li>
<li>Redox: Add <code>renameat2</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4968">#4968</a>)</li>
</ul>
<h2>0.2.181</h2>
<h3>Added</h3>
<ul>
<li>Apple: Add <code>MADV_ZERO</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4924">#4924</a>)</li>
<li>Redox: Add <code>makedev</code>, <code>major</code>, and
<code>minor</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4928">#4928</a>)</li>
<li>GLibc: Add <code>PTRACE_SET_SYSCALL_INFO</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4933">#4933</a>)</li>
<li>OpenBSD: Add more kqueue related constants for (<a
href="https://redirect.github.com/rust-lang/libc/pull/4945">#4945</a>)</li>
<li>Linux: add CAN error types (<a
href="https://redirect.github.com/rust-lang/libc/pull/4944">#4944</a>)</li>
<li>OpenBSD: Add siginfo_t::si_status (<a
href="https://redirect.github.com/rust-lang/libc/pull/4946">#4946</a>)</li>
<li>QNX NTO: Add <code>max_align_t</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4927">#4927</a>)</li>
<li>Illumos: Add <code>_CS_PATH</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4956">#4956</a>)</li>
<li>OpenBSD: add <code>ppoll</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4957">#4957</a>)</li>
</ul>
<h3>Fixed</h3>
<ul>
<li><strong>Breaking</strong>: Redox: Fix the type of <code>dev_t</code>
(<a
href="https://redirect.github.com/rust-lang/libc/pull/4928">#4928</a>)</li>
<li>AIX: Change 'tv_nsec' of 'struct timespec' to type 'c_long' (<a
href="https://redirect.github.com/rust-lang/libc/pull/4931">#4931</a>)</li>
<li>AIX: Use 'struct st_timespec' in 'struct stat{,64}' (<a
href="https://redirect.github.com/rust-lang/libc/pull/4931">#4931</a>)</li>
<li>Glibc: Link old version of <code>tc{g,s}etattr</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4938">#4938</a>)</li>
<li>Glibc: Link the correct version of <code>cf{g,s}et{i,o}speed</code>
on mips{32,64}r6 (<a
href="https://redirect.github.com/rust-lang/libc/pull/4938">#4938</a>)</li>
<li>OpenBSD: Fix constness of tm.tm_zone (<a
href="https://redirect.github.com/rust-lang/libc/pull/4948">#4948</a>)</li>
<li>OpenBSD: Fix the definition of <code>ptrace_thread_state</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4947">#4947</a>)</li>
<li>QuRT: Fix type visibility and defs (<a
href="https://redirect.github.com/rust-lang/libc/pull/4932">#4932</a>)</li>
<li>Redox: Fix values for <code>PTHREAD_MUTEX_{NORMAL, RECURSIVE}</code>
(<a
href="https://redirect.github.com/rust-lang/libc/pull/4943">#4943</a>)</li>
<li>Various: Mark additional fields as private padding (<a
href="https://redirect.github.com/rust-lang/libc/pull/4922">#4922</a>)</li>
</ul>
<h3>Changed</h3>
<ul>
<li>Fuchsia: Update <code>SO_*</code> constants (<a
href="https://redirect.github.com/rust-lang/libc/pull/4937">#4937</a>)</li>
<li>Revert "musl: convert inline timespecs to timespec"
(resolves build issues on targets only supported by Musl 1.2.3+ ) (<a
href="https://redirect.github.com/rust-lang/libc/pull/4958">#4958</a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/rust-lang/libc/blob/0.2.182/CHANGELOG.md">libc's
changelog</a>.</em></p>
<blockquote>
<h2><a
href="https://github.com/rust-lang/libc/compare/0.2.181...0.2.182">0.2.182</a>
- 2026-02-13</h2>
<h3>Added</h3>
<ul>
<li>Android, Linux: Add <code>tgkill</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4970">#4970</a>)</li>
<li>Redox: Add <code>RENAME_NOREPLACE</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4968">#4968</a>)</li>
<li>Redox: Add <code>renameat2</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4968">#4968</a>)</li>
</ul>
<h2><a
href="https://github.com/rust-lang/libc/compare/0.2.180...0.2.181">0.2.181</a>
- 2026-02-09</h2>
<h3>Added</h3>
<ul>
<li>Apple: Add <code>MADV_ZERO</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4924">#4924</a>)</li>
<li>Redox: Add <code>makedev</code>, <code>major</code>, and
<code>minor</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4928">#4928</a>)</li>
<li>GLibc: Add <code>PTRACE_SET_SYSCALL_INFO</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4933">#4933</a>)</li>
<li>OpenBSD: Add more kqueue related constants for (<a
href="https://redirect.github.com/rust-lang/libc/pull/4945">#4945</a>)</li>
<li>Linux: add CAN error types (<a
href="https://redirect.github.com/rust-lang/libc/pull/4944">#4944</a>)</li>
<li>OpenBSD: Add siginfo_t::si_status (<a
href="https://redirect.github.com/rust-lang/libc/pull/4946">#4946</a>)</li>
<li>QNX NTO: Add <code>max_align_t</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4927">#4927</a>)</li>
<li>Illumos: Add <code>_CS_PATH</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4956">#4956</a>)</li>
<li>OpenBSD: add <code>ppoll</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4957">#4957</a>)</li>
</ul>
<h3>Fixed</h3>
<ul>
<li><strong>breaking</strong>: Redox: Fix the type of dev_t (<a
href="https://redirect.github.com/rust-lang/libc/pull/4928">#4928</a>)</li>
<li>AIX: Change 'tv_nsec' of 'struct timespec' to type 'c_long' (<a
href="https://redirect.github.com/rust-lang/libc/pull/4931">#4931</a>)</li>
<li>AIX: Use 'struct st_timespec' in 'struct stat{,64}' (<a
href="https://redirect.github.com/rust-lang/libc/pull/4931">#4931</a>)</li>
<li>Glibc: Link old version of <code>tc{g,s}etattr</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4938">#4938</a>)</li>
<li>Glibc: Link the correct version of <code>cf{g,s}et{i,o}speed</code>
on mips{32,64}r6 (<a
href="https://redirect.github.com/rust-lang/libc/pull/4938">#4938</a>)</li>
<li>OpenBSD: Fix constness of tm.tm_zone (<a
href="https://redirect.github.com/rust-lang/libc/pull/4948">#4948</a>)</li>
<li>OpenBSD: Fix the definition of <code>ptrace_thread_state</code> (<a
href="https://redirect.github.com/rust-lang/libc/pull/4947">#4947</a>)</li>
<li>QuRT: Fix type visibility and defs (<a
href="https://redirect.github.com/rust-lang/libc/pull/4932">#4932</a>)</li>
<li>Redox: Fix values for <code>PTHREAD_MUTEX_{NORMAL, RECURSIVE}</code>
(<a
href="https://redirect.github.com/rust-lang/libc/pull/4943">#4943</a>)</li>
<li>Various: Mark additional fields as private padding (<a
href="https://redirect.github.com/rust-lang/libc/pull/4922">#4922</a>)</li>
</ul>
<h3>Changed</h3>
<ul>
<li>Fuchsia: Update <code>SO_*</code> constants (<a
href="https://redirect.github.com/rust-lang/libc/pull/4937">#4937</a>)</li>
<li>Revert "musl: convert inline timespecs to timespec"
(resolves build issues on targets only supported by Musl 1.2.3+ ) (<a
href="https://redirect.github.com/rust-lang/libc/pull/4958">#4958</a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/rust-lang/libc/commit/e879ee90b6cd8f79b352d4d4d1f8ca05f94f2f53"><code>e879ee9</code></a>
chore: Release libc 0.2.182</li>
<li><a
href="https://github.com/rust-lang/libc/commit/2efe72f4dae6feebacaf5ec8a4ec5fdc79569e7b"><code>2efe72f</code></a>
remove copyright year in LICENSE-MIT</li>
<li><a
href="https://github.com/rust-lang/libc/commit/634bc4e66e944d54ebc3d1610175c8c6d390bd29"><code>634bc4e</code></a>
ci: Update the list of tested and documented targets</li>
<li><a
href="https://github.com/rust-lang/libc/commit/d7aa109ab5074dbbd35fb52cc72620e29961e76d"><code>d7aa109</code></a>
Revert "Disable hexagon-unknown-linux-musl testing for
now"</li>
<li><a
href="https://github.com/rust-lang/libc/commit/14e2f5641e2d4356953b0c95959ccfc86af5dcc3"><code>14e2f56</code></a>
Revert "ci: Skip hexagon-unknown-linux-musl"</li>
<li><a
href="https://github.com/rust-lang/libc/commit/b7807c369b468c369661e81ea6f9f649f3b3ddf3"><code>b7807c3</code></a>
Revert "aix: Temporarily skip checking powerpc64-ibm-aix
builds"</li>
<li><a
href="https://github.com/rust-lang/libc/commit/abe93a0bfedfe6159252d43e5c4273d0b0833ca4"><code>abe93a0</code></a>
feat(linux): add <code>tgkill</code> for Linux and Android</li>
<li><a
href="https://github.com/rust-lang/libc/commit/25f7dde943988c81871d95aaea1afd49cf11425d"><code>25f7dde</code></a>
feat(redox): add <code>RENAME_NOREPLACE</code></li>
<li><a
href="https://github.com/rust-lang/libc/commit/4b4ce4f2205d22121c5e913b118f8fc776d39897"><code>4b4ce4f</code></a>
feat(redox): add <code>renameat2</code></li>
<li><a
href="https://github.com/rust-lang/libc/commit/ab8c36c49327eeee2b5c3818d6706b499dd890a4"><code>ab8c36c</code></a>
build(deps): bump vmactions/solaris-vm from 1.2.8 to 1.3.0</li>
<li>Additional commits viewable in <a
href="https://github.com/rust-lang/libc/compare/0.2.180...0.2.182">compare
view</a></li>
</ul>
</details>
<br />
[](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 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>
2026-02-23 10:24:35 -08:00
|
|
|
libc = "0.2.182"
|
2025-09-22 18:47:01 +02:00
|
|
|
log = "0.4"
|
2026-01-07 10:11:27 -08:00
|
|
|
lru = "0.16.3"
|
2025-09-22 18:47:01 +02:00
|
|
|
maplit = "1.0.2"
|
|
|
|
|
mime_guess = "2.0.5"
|
|
|
|
|
multimap = "0.10.0"
|
2025-10-15 09:56:59 +01:00
|
|
|
notify = "8.2.0"
|
2026-01-28 10:54:43 -08:00
|
|
|
nucleo = { git = "https://github.com/helix-editor/nucleo.git", rev = "4253de9faabb4e5c6d81d946a5e35a90f87347ee" }
|
2025-11-21 13:36:17 -08:00
|
|
|
once_cell = "1.20.2"
|
2025-09-22 18:47:01 +02:00
|
|
|
openssl-sys = "*"
|
chore(deps): bump tracing-opentelemetry from 0.31.0 to 0.32.0 in /codex-rs (#8415)
Bumps
[tracing-opentelemetry](https://github.com/tokio-rs/tracing-opentelemetry)
from 0.31.0 to 0.32.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/tokio-rs/tracing-opentelemetry/releases">tracing-opentelemetry's
releases</a>.</em></p>
<blockquote>
<h2>0.32.0</h2>
<h3>Added</h3>
<ul>
<li>Add configuration for including <code>target</code> in spans (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/222">#222</a>)</li>
</ul>
<h3>Changed</h3>
<ul>
<li>OpenTelemetry context activation (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/202">#202</a>)
<ul>
<li>Trace ID and span ID can be obtained from <code>OtelData</code> via
dedicated functions. Note that these
will be available only if the context has already been built. (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/issues/233">#233</a>)</li>
</ul>
</li>
<li>Correctly track entered and exited state for timings (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/212">#212</a>)</li>
<li>Slightly improve error message on version mismatch (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/211">#211</a>)</li>
<li>Remove Lazy for thread_local static (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/215">#215</a>)</li>
<li>Update description of special fields and semantic conventions</li>
</ul>
<h3>Breaking Changes</h3>
<ul>
<li>The attributes <code>code.filepath</code>, <code>code.lineno</code>,
and <code>code.namespace</code> have been renamed to
<code>code.file.path</code>, and <code>code.line.number</code>, and
<code>code.module.name</code>, to align with the opentelemetry
semantic conventions for code. (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/225">#225</a>)</li>
<li>Upgrade from opentelemetry to 0.31.0. Refer to the upstream
<a
href="https://github.com/open-telemetry/opentelemetry-rust/blob/main/opentelemetry-sdk/CHANGELOG.md#0310">changelog</a>
for more information. (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/230">#230</a>)</li>
<li>Hold onto <code>MetricsProvider</code> in <code>MetricsLayer</code>
(<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/224">#224</a>)</li>
<li>The attribute <code>otel.status_message</code> was changed to
<code>otel.status_description</code> to align with the
opentelemetry semantic conventions for code. (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/209">#209</a>)</li>
<li>Remove the <code>metrics_gauge_unstable</code> feature.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/tokio-rs/tracing-opentelemetry/blob/v0.1.x/CHANGELOG.md">tracing-opentelemetry's
changelog</a>.</em></p>
<blockquote>
<h2><a
href="https://github.com/tokio-rs/tracing-opentelemetry/compare/v0.31.0...v0.32.0">0.32.0</a>
- 2025-09-29</h2>
<h3>Added</h3>
<ul>
<li>Add configuration for including <code>target</code> in spans (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/222">#222</a>)</li>
</ul>
<h3>Changed</h3>
<ul>
<li>OpenTelemetry context activation (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/202">#202</a>)
<ul>
<li>Trace ID and span ID can be obtained from <code>OtelData</code> via
dedicated functions. Note that these
will be available only if the context has already been built. (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/issues/233">#233</a>)</li>
</ul>
</li>
<li>Correctly track entered and exited state for timings (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/212">#212</a>)</li>
<li>Slightly improve error message on version mismatch (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/211">#211</a>)</li>
<li>Remove Lazy for thread_local static (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/215">#215</a>)</li>
<li>Update description of special fields and semantic conventions</li>
</ul>
<h3>Breaking Changes</h3>
<ul>
<li>The attributes <code>code.filepath</code>, <code>code.lineno</code>,
and <code>code.namespace</code> have been renamed to
<code>code.file.path</code>, and <code>code.line.number</code>, and
<code>code.module.name</code>, to align with the opentelemetry
semantic conventions for code. (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/225">#225</a>)</li>
<li>Upgrade from opentelemetry to 0.31.0. Refer to the upstream
<a
href="https://github.com/open-telemetry/opentelemetry-rust/blob/main/opentelemetry-sdk/CHANGELOG.md#0310">changelog</a>
for more information. (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/230">#230</a>)</li>
<li>Hold onto <code>MetricsProvider</code> in <code>MetricsLayer</code>
(<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/224">#224</a>)</li>
<li>The attribute <code>otel.status_message</code> was changed to
<code>otel.status_description</code> to align with the
opentelemetry semantic conventions for code. (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/209">#209</a>)</li>
<li>Remove the <code>metrics_gauge_unstable</code> feature.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/tokio-rs/tracing-opentelemetry/commit/f663332dd81a9f37d4b6c61969596d6ff552202b"><code>f663332</code></a>
chore: prepare release of 0.32.0</li>
<li><a
href="https://github.com/tokio-rs/tracing-opentelemetry/commit/0154fa470b711c27d26d8bd3f2a7918b53203d75"><code>0154fa4</code></a>
chore: fix docs link</li>
<li><a
href="https://github.com/tokio-rs/tracing-opentelemetry/commit/d684c2ee368c8d87f7d409f44701117ac6032f9f"><code>d684c2e</code></a>
chore: delete removed docs.rs feature</li>
<li><a
href="https://github.com/tokio-rs/tracing-opentelemetry/commit/73a6baf71df28d7dd0b56e1131dc4e3177975f0f"><code>73a6baf</code></a>
feat: make trace ID and span ID public on <code>OtelData</code> (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/issues/233">#233</a>)</li>
<li><a
href="https://github.com/tokio-rs/tracing-opentelemetry/commit/4ebae2c53792e76c71d47c0f651b8fb059094540"><code>4ebae2c</code></a>
Upgrade to <code>opentelemetry</code> 0.31 (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/issues/230">#230</a>)</li>
<li><a
href="https://github.com/tokio-rs/tracing-opentelemetry/commit/4fdf56048d1e710a3fd2164a57ba8ce3b7bd10d4"><code>4fdf560</code></a>
fix(layer)!: use otel semantic conventions for code (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/issues/225">#225</a>)</li>
<li><a
href="https://github.com/tokio-rs/tracing-opentelemetry/commit/612b5b2601e7db0c98efbb2fcde0a781593255c7"><code>612b5b2</code></a>
chore: fix clippy lints (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/issues/226">#226</a>)</li>
<li><a
href="https://github.com/tokio-rs/tracing-opentelemetry/commit/c4fe96ac2a51bb1e60293aeb7346c3584bcdf4d3"><code>c4fe96a</code></a>
feat: OpenTelemetry context activation (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/issues/202">#202</a>)</li>
<li><a
href="https://github.com/tokio-rs/tracing-opentelemetry/commit/764cd7365fd331ace160c7d539ed08761c16cd66"><code>764cd73</code></a>
fix(metrics)!: hold onto <code>MetricsProvider</code> in
<code>MetricsLayer</code> (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/issues/224">#224</a>)</li>
<li><a
href="https://github.com/tokio-rs/tracing-opentelemetry/commit/fd0a58a7f48d5c6fe959dd9f856755893707694b"><code>fd0a58a</code></a>
feat(layer): add configuration for including <code>target</code> in
spans (<a
href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/issues/222">#222</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/tokio-rs/tracing-opentelemetry/compare/v0.31.0...v0.32.0">compare
view</a></li>
</ul>
</details>
<br />
[](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>
Co-authored-by: Anton Panasenko <apanasenko@openai.com>
2026-01-02 16:38:16 -08:00
|
|
|
opentelemetry = "0.31.0"
|
|
|
|
|
opentelemetry-appender-tracing = "0.31.0"
|
|
|
|
|
opentelemetry-otlp = "0.31.0"
|
|
|
|
|
opentelemetry-semantic-conventions = "0.31.0"
|
|
|
|
|
opentelemetry_sdk = "0.31.0"
|
2025-09-22 18:47:01 +02:00
|
|
|
os_info = "3.12.0"
|
2026-02-23 13:01:15 -08:00
|
|
|
owo-colors = "4.3.0"
|
2025-09-22 18:47:01 +02:00
|
|
|
path-absolutize = "3.1.1"
|
|
|
|
|
pathdiff = "0.2"
|
|
|
|
|
portable-pty = "0.9.0"
|
|
|
|
|
predicates = "3"
|
|
|
|
|
pretty_assertions = "1.4.1"
|
|
|
|
|
pulldown-cmark = "0.10"
|
[hooks] use a user message > developer message for prompt continuation (#14867)
## Summary
Persist Stop-hook continuation prompts as `user` messages instead of
hidden `developer` messages + some requested integration tests
This is a followup to @pakrym 's comment in
https://github.com/openai/codex/pull/14532 to make sure stop-block
continuation prompts match training for turn loops
- Stop continuation now writes `<hook_prompt hook_run_id="...">stop
hook's user prompt<hook_prompt>`
- Introduces quick-xml dependency, though we already indirectly depended
on it anyway via syntect
- This PR only has about 500 lines of actual logic changes, the rest is
tests/schema
## Testing
Example run (with a sessionstart hook and 3 stop hooks) - this shows
context added by session start, then two stop hooks sending their own
additional prompts in a new turn. The model responds with a single
message addressing both. Then when that turn ends, the hooks detect that
they just ran using `stop_hook_active` and decide not to infinite loop
test files for this (unzip, move codex -> .codex):
[codex.zip](https://github.com/user-attachments/files/26075806/codex.zip)
```
› cats
• Running SessionStart hook: lighting the observatory
SessionStart hook (completed)
warning: Hi, I'm a session start hook for wizard-tower (startup).
hook context: A wimboltine stonpet is an exotic cuisine from hyperspace
• Cats are tiny zen wizards, my friend: equal parts nap, mystery, and chaos. If you want, we can talk
cat facts, cat breeds, cat names, or build something cat-themed in this repo.
• Running Stop hook: checking the tower wards
• Running Stop hook: sacking the guards
• Running Stop hook: hiring the guards
Stop hook (completed)
warning: Wizard Tower Stop hook reviewed the completed reply (177 chars).
Stop hook (blocked)
warning: Wizard Tower Stop hook continuing conversation
feedback: cook the stonpet
Stop hook (blocked)
warning: Wizard Tower Stop hook continuing conversation
feedback: eat the cooked stonpet
• Stonpet’s cooked, aloha style: flash-seared over a blue quasiflame, glazed with nebula salt, and
rested until the hyperspace juices settle.
Now we eat with gratitude, my friend. One mindful bite in, and the flavor is pure cosmic surf:
smoky, bright, and totally out of this dimension.
• Running Stop hook: checking the tower wards
• Running Stop hook: sacking the guards
• Running Stop hook: hiring the guards
Stop hook (completed)
warning: Wizard Tower Stop hook reviewed the completed reply (285 chars).
Stop hook (completed)
warning: Wizard Tower Stop hook saw a second pass and stayed calm to avoid a loop.
Stop hook (completed)
warning: Wizard Tower Stop hook saw a second pass and stayed calm to avoid a loop.
```
2026-03-19 10:53:08 -07:00
|
|
|
quick-xml = "0.38.4"
|
2025-09-22 18:47:01 +02:00
|
|
|
rand = "0.9"
|
|
|
|
|
ratatui = "0.29.0"
|
2025-10-20 14:40:14 -07:00
|
|
|
ratatui-macros = "0.6.0"
|
2026-02-09 21:34:22 -08:00
|
|
|
regex = "1.12.3"
|
2025-12-29 21:08:20 -07:00
|
|
|
regex-lite = "0.1.8"
|
2026-01-24 22:58:56 -08:00
|
|
|
reqwest = "0.12"
|
2026-02-11 22:04:17 -08:00
|
|
|
rmcp = { version = "0.15.0", default-features = false }
|
2026-01-28 19:15:44 -05:00
|
|
|
runfiles = { git = "https://github.com/dzbarsky/rules_rust", rev = "b56cbaa8465e74127f1ea216f813cd377295ad81" }
|
2026-03-20 12:08:25 -07:00
|
|
|
v8 = "=146.4.0"
|
2026-02-11 10:02:49 -08:00
|
|
|
rustls = { version = "0.23", default-features = false, features = [
|
|
|
|
|
"ring",
|
|
|
|
|
"std",
|
|
|
|
|
] }
|
client: extend custom CA handling across HTTPS and websocket clients (#14239)
## Stacked PRs
This work is now effectively split across two steps:
- #14178: add custom CA support for browser and device-code login flows,
docs, and hermetic subprocess tests
- #14239: extend that shared custom CA handling across Codex HTTPS
clients and secure websocket TLS
Note: #14240 was merged into this branch while it was stacked on top of
this PR. This PR now subsumes that websocket follow-up and should be
treated as the combined change.
Builds on top of #14178.
## Problem
Custom CA support landed first in the login path, but the real
requirement is broader. Codex constructs outbound TLS clients in
multiple places, and both HTTPS and secure websocket paths can fail
behind enterprise TLS interception if they do not honor
`CODEX_CA_CERTIFICATE` or `SSL_CERT_FILE` consistently.
This PR broadens the shared custom-CA logic beyond login and applies the
same policy to websocket TLS, so the enterprise-proxy story is no longer
split between “HTTPS works” and “websockets still fail”.
## What This Delivers
Custom CA support is no longer limited to login. Codex outbound HTTPS
clients and secure websocket connections can now honor the same
`CODEX_CA_CERTIFICATE` / `SSL_CERT_FILE` configuration, so enterprise
proxy/intercept setups work more consistently end-to-end.
For users and operators, nothing new needs to be configured beyond the
same CA env vars introduced in #14178. The change is that more of Codex
now respects them, including websocket-backed flows that were previously
still using default trust roots.
I also manually validated the proxy path locally with mitmproxy using:
`CODEX_CA_CERTIFICATE=~/.mitmproxy/mitmproxy-ca-cert.pem
HTTPS_PROXY=http://127.0.0.1:8080 just codex`
with mitmproxy installed via `brew install mitmproxy` and configured as
the macOS system proxy.
## Mental model
`codex-client` is now the owner of shared custom-CA policy for outbound
TLS client construction. Reqwest callers start from the builder
configuration they already need, then pass that builder through
`build_reqwest_client_with_custom_ca(...)`. Websocket callers ask the
same module for a rustls client config when a custom CA bundle is
configured.
The env precedence is the same everywhere:
- `CODEX_CA_CERTIFICATE` wins
- otherwise fall back to `SSL_CERT_FILE`
- otherwise use system roots
The helper is intentionally narrow. It loads every usable certificate
from the configured PEM bundle into the appropriate root store and
returns either a configured transport or a typed error that explains
what went wrong.
## Non-goals
This does not add handshake-level integration tests against a live TLS
endpoint. It does not validate that the configured bundle forms a
meaningful certificate chain. It also does not try to force every
transport in the repo through one abstraction; it extends the shared CA
policy across the reqwest and websocket paths that actually needed it.
## Tradeoffs
The main tradeoff is centralizing CA behavior in `codex-client` while
still leaving adoption up to call sites. That keeps the implementation
additive and reviewable, but it means the rule "outbound Codex TLS that
should honor enterprise roots must use the shared helper" is still
partly enforced socially rather than by types.
For websockets, the shared helper only builds an explicit rustls config
when a custom CA bundle is configured. When no override env var is set,
websocket callers still use their ordinary default connector path.
## Architecture
`codex-client::custom_ca` now owns CA bundle selection, PEM
normalization, mixed-section parsing, certificate extraction, typed
CA-loading errors, and optional rustls client-config construction for
websocket TLS.
The affected consumers now call into that shared helper directly rather
than carrying login-local CA behavior:
- backend-client
- cloud-tasks
- RMCP client paths that use `reqwest`
- TUI voice HTTP paths
- `codex-core` default reqwest client construction
- `codex-api` websocket clients for both responses and realtime
websocket connections
The subprocess CA probe, env-sensitive integration tests, and shared PEM
fixtures also live in `codex-client`, which is now the actual owner of
the behavior they exercise.
## Observability
The shared CA path logs:
- which environment variable selected the bundle
- which path was loaded
- how many certificates were accepted
- when `TRUSTED CERTIFICATE` labels were normalized
- when CRLs were ignored
- where client construction failed
Returned errors remain user-facing and include the relevant env var,
path, and remediation hint. That same error model now applies whether
the failure surfaced while building a reqwest client or websocket TLS
configuration.
## Tests
Pure unit tests in `codex-client` cover env precedence and PEM
normalization behavior. Real client construction remains in subprocess
tests so the suite can control process env and avoid the macOS seatbelt
panic path that motivated the hermetic test split.
The subprocess coverage verifies:
- `CODEX_CA_CERTIFICATE` precedence over `SSL_CERT_FILE`
- fallback to `SSL_CERT_FILE`
- single-cert and multi-cert bundles
- malformed and empty-file errors
- OpenSSL `TRUSTED CERTIFICATE` handling
- CRL tolerance for well-formed CRL sections
The websocket side is covered by the existing `codex-api` / `codex-core`
websocket test suites plus the manual mitmproxy validation above.
---------
Co-authored-by: Ivan Zakharchanka <3axap4eHko@gmail.com>
Co-authored-by: Codex <noreply@openai.com>
2026-03-12 17:59:26 -07:00
|
|
|
rustls-native-certs = "0.8.3"
|
login: add custom CA support for login flows (#14178)
## Stacked PRs
This work is split across three stacked PRs:
- #14178: add custom CA support for browser and device-code login flows,
docs, and hermetic subprocess tests
- #14239: broaden the shared custom CA path from login to other outbound
`reqwest` clients across Codex
- #14240: extend that shared custom CA handling to secure websocket TLS
so websocket connections honor the same CA env vars
Review order: #14178, then #14239, then #14240.
Supersedes #6864.
Thanks to @3axap4eHko for the original implementation and investigation
here. Although this version rearranges the code and history
significantly, the majority of the credit for this work belongs to them.
## Problem
Login flows need to work in enterprise environments where outbound TLS
is intercepted by an internal proxy or gateway. In those setups, system
root certificates alone are often insufficient to validate the OAuth and
device-code endpoints used during login. The change adds a
login-specific custom CA loading path, but the important contracts
around env precedence, PEM compatibility, test boundaries, and
probe-only workarounds need to be explicit so reviewers can understand
what behavior is intentional.
For users and operators, the behavior is simple: if login needs to trust
a custom root CA, set `CODEX_CA_CERTIFICATE` to a PEM file containing
one or more certificates. If that variable is unset, login falls back to
`SSL_CERT_FILE`. If neither is set, login uses system roots. Invalid or
empty PEM files now fail with an error that points back to those
environment variables and explains how to recover.
## What This Delivers
Users can now make Codex login work behind enterprise TLS interception
by pointing `CODEX_CA_CERTIFICATE` at a PEM bundle containing the
relevant root certificates. If that variable is unset, login falls back
to `SSL_CERT_FILE`, then to system roots.
This PR applies that behavior to both browser-based and device-code
login flows. It also makes login tolerant of the PEM shapes operators
actually have in hand: multi-certificate bundles, OpenSSL `TRUSTED
CERTIFICATE` labels, and bundles that include well-formed CRLs.
## Mental model
`codex-login` is the place where the login flows construct ad hoc
outbound HTTP clients. That makes it the right boundary for a narrow CA
policy: look for `CODEX_CA_CERTIFICATE`, fall back to `SSL_CERT_FILE`,
load every parseable certificate block in that bundle into a
`reqwest::Client`, and fail early with a clear user-facing error if the
bundle is unreadable or malformed.
The implementation is intentionally pragmatic about PEM input shape. It
accepts ordinary certificate bundles, multi-certificate bundles, OpenSSL
`TRUSTED CERTIFICATE` labels, and bundles that also contain CRLs. It
does not validate a certificate chain or prove a handshake; it only
constructs the root store used by login.
## Non-goals
This change does not introduce a general-purpose transport abstraction
for the rest of the product. It does not validate whether the provided
bundle forms a real chain, and it does not add handshake-level
integration tests against a live TLS server. It also does not change
login state management or OAuth semantics beyond ensuring the existing
flows share the same CA-loading rules.
## Tradeoffs
The main tradeoff is keeping this logic scoped to login-specific client
construction rather than lifting it into a broader shared HTTP layer.
That keeps the review surface smaller, but it also means future
login-adjacent code must continue to use `build_login_http_client()` or
it can silently bypass enterprise CA overrides.
The `TRUSTED CERTIFICATE` handling is also intentionally a local
compatibility shim. The rustls ecosystem does not currently accept that
PEM label upstream, so the code normalizes it locally and trims the
OpenSSL `X509_AUX` trailer bytes down to the certificate DER that
`reqwest` can consume.
## Architecture
`custom_ca.rs` is now the single place that owns login CA behavior. It
selects the CA file from the environment, reads it, normalizes PEM label
shape where needed, iterates mixed PEM sections with `rustls-pki-types`,
ignores CRLs, trims OpenSSL trust metadata when necessary, and returns
either a configured `reqwest::Client` or a typed error.
The browser login server and the device-code flow both call
`build_login_http_client()`, so they share the same trust-store policy.
Environment-sensitive tests run through the `login_ca_probe` helper
binary because those tests must control process-wide env vars and cannot
reliably build a real reqwest client in-process on macOS seatbelt runs.
## Observability
The custom CA path logs which environment variable selected the bundle,
which file path was loaded, how many certificates were accepted, when
`TRUSTED CERTIFICATE` labels were normalized, when CRLs were ignored,
and where client construction failed. Returned errors remain user-facing
and include the relevant path, env var, and remediation hint.
This gives enough signal for three audiences:
- users can see why login failed and which env/file caused it
- sysadmins can confirm which override actually won
- developers can tell whether the failure happened during file read, PEM
parsing, certificate registration, or final reqwest client construction
## Tests
Pure unit tests stay limited to env precedence and empty-value handling.
Real client construction lives in subprocess tests so the suite remains
hermetic with respect to process env and macOS sandbox behavior.
The subprocess tests verify:
- `CODEX_CA_CERTIFICATE` precedence over `SSL_CERT_FILE`
- fallback to `SSL_CERT_FILE`
- single-certificate and multi-certificate bundles
- malformed and empty-bundle errors
- OpenSSL `TRUSTED CERTIFICATE` handling
- CRL tolerance for well-formed CRL sections
The named PEM fixtures under `login/tests/fixtures/` are shared by the
tests so their purpose stays reviewable.
---------
Co-authored-by: Ivan Zakharchanka <3axap4eHko@gmail.com>
Co-authored-by: Codex <noreply@openai.com>
2026-03-12 17:14:54 -07:00
|
|
|
rustls-pki-types = "1.14.0"
|
2025-09-22 18:47:01 +02:00
|
|
|
schemars = "0.8.22"
|
|
|
|
|
seccompiler = "0.5.0"
|
2026-02-11 10:02:49 -08:00
|
|
|
semver = "1.0"
|
chore(deps): bump sentry from 0.34.0 to 0.46.0 in /codex-rs (#8043)
Bumps [sentry](https://github.com/getsentry/sentry-rust) from 0.34.0 to
0.46.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/getsentry/sentry-rust/releases">sentry's
releases</a>.</em></p>
<blockquote>
<h2>0.46.0</h2>
<h3>Breaking changes</h3>
<ul>
<li>Removed the <code>ClientOptions</code> struct's
<code>trim_backtraces</code> and <code>extra_border_frames</code> fields
(<a
href="https://redirect.github.com/getsentry/sentry-rust/pull/925">#925</a>).
<ul>
<li>These fields configured backtrace trimming, which is being removed
in this release.</li>
</ul>
</li>
</ul>
<h3>Improvements</h3>
<ul>
<li>Removed backtrace trimming to align the Rust SDK with the general
principle that Sentry SDKs should only truncate telemetry data when
needed to comply with <a
href="https://develop.sentry.dev/sdk/data-model/envelopes/#size-limits">documented
size limits</a> (<a
href="https://redirect.github.com/getsentry/sentry-rust/pull/925">#925</a>).
This change ensures that as much data as possible remains available for
debugging.
<ul>
<li>If you notice any new issues being created for existing errors after
this change, please open an issue on <a
href="https://github.com/getsentry/sentry-rust/issues/new/choose">GitHub</a>.</li>
</ul>
</li>
</ul>
<h3>Fixes</h3>
<ul>
<li>fix: adjust sentry.origin for log integration (<a
href="https://redirect.github.com/getsentry/sentry-rust/pull/919">#919</a>)
by <a href="https://github.com/lcian"><code>@lcian</code></a></li>
</ul>
<h2>0.45.0</h2>
<h3>Breaking changes</h3>
<ul>
<li>Add custom variant to <code>AttachmentType</code> that holds an
arbitrary String. (<a
href="https://redirect.github.com/getsentry/sentry-rust/pull/916">#916</a>)</li>
</ul>
<h2>0.44.0</h2>
<h3>Breaking changes</h3>
<ul>
<li>feat(log): support combined LogFilters and RecordMappings (<a
href="https://redirect.github.com/getsentry/sentry-rust/pull/914">#914</a>)
by <a href="https://github.com/lcian"><code>@lcian</code></a>
<ul>
<li>Breaking change: <code>sentry::integrations::log::LogFilter</code>
has been changed to a <code>bitflags</code> struct.</li>
<li>It's now possible to map a <code>log</code> record to multiple items
in Sentry by combining multiple log filters in the filter, e.g.
<code>log::Level::ERROR => LogFilter::Event |
LogFilter::Log</code>.</li>
<li>If using a custom <code>mapper</code> instead, it's possible to
return a
<code>Vec<sentry::integrations::log::RecordMapping></code> to map
a <code>log</code> record to multiple items in Sentry.</li>
</ul>
</li>
</ul>
<h3>Behavioral changes</h3>
<ul>
<li>ref(log): send logs by default when logs feature flag is enabled (<a
href="https://redirect.github.com/getsentry/sentry-rust/pull/915">#915</a>)
by <a href="https://github.com/lcian"><code>@lcian</code></a>
<ul>
<li>If the <code>logs</code> feature flag is enabled, the default Sentry
<code>log</code> logger now sends logs for all events at or above
INFO.</li>
</ul>
</li>
<li>ref(logs): enable logs by default if logs feature flag is used (<a
href="https://redirect.github.com/getsentry/sentry-rust/pull/910">#910</a>)
by <a href="https://github.com/lcian"><code>@lcian</code></a>
<ul>
<li>This changes the default value of
<code>sentry::ClientOptions::enable_logs</code> to
<code>true</code>.</li>
<li>This simplifies the setup of Sentry structured logs by requiring
users to just add the <code>log</code> feature flag to the
<code>sentry</code> dependency to opt-in to sending logs.</li>
<li>When the <code>log</code> feature flag is enabled, the
<code>tracing</code> and <code>log</code> integrations will send
structured logs to Sentry for all logs/events at or above INFO level by
default.</li>
</ul>
</li>
</ul>
<h2>0.43.0</h2>
<h3>Breaking changes</h3>
<ul>
<li>ref(tracing): rework tracing to Sentry span name/op conversion (<a
href="https://redirect.github.com/getsentry/sentry-rust/pull/887">#887</a>)
by <a href="https://github.com/lcian"><code>@lcian</code></a>
<ul>
<li>The <code>tracing</code> integration now uses the tracing span name
as the Sentry span name by default.</li>
<li>Before this change, the span name would be set based on the
<code>tracing</code> span target
(<code><module>::<function></code> when using the
<code>tracing::instrument</code> macro).</li>
<li>The <code>tracing</code> integration now uses <code><span
target>::<span name></code> as the default Sentry span op (i.e.
<code><module>::<function></code> when using
<code>tracing::instrument</code>).</li>
<li>Before this change, the span op would be set based on the
<code>tracing</code> span name.</li>
<li>Read below to learn how to customize the span name and op.</li>
<li>When upgrading, please ensure to adapt any queries, metrics or
dashboards to use the new span names/ops.</li>
</ul>
</li>
<li>ref(tracing): use standard code attributes (<a
href="https://redirect.github.com/getsentry/sentry-rust/pull/899">#899</a>)
by <a href="https://github.com/lcian"><code>@lcian</code></a>
<ul>
<li>Logs now carry the attributes <code>code.module.name</code>,
<code>code.file.path</code> and <code>code.line.number</code>
standardized in OTEL to surface the respective information, in contrast
with the previously sent <code>tracing.module_path</code>,
<code>tracing.file</code> and <code>tracing.line</code>.</li>
</ul>
</li>
<li>fix(actix): capture only server errors (<a
href="https://redirect.github.com/getsentry/sentry-rust/pull/877">#877</a>)
by <a href="https://github.com/lcian"><code>@lcian</code></a></li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/getsentry/sentry-rust/blob/master/CHANGELOG.md">sentry's
changelog</a>.</em></p>
<blockquote>
<h2>0.46.0</h2>
<h3>Breaking changes</h3>
<ul>
<li>Removed the <code>ClientOptions</code> struct's
<code>trim_backtraces</code> and <code>extra_border_frames</code> fields
(<a
href="https://redirect.github.com/getsentry/sentry-rust/pull/925">#925</a>).
<ul>
<li>These fields configured backtrace trimming, which is being removed
in this release.</li>
</ul>
</li>
</ul>
<h3>Improvements</h3>
<ul>
<li>Removed backtrace trimming to align the Rust SDK with the general
principle that Sentry SDKs should only truncate telemetry data when
needed to comply with <a
href="https://develop.sentry.dev/sdk/data-model/envelopes/#size-limits">documented
size limits</a> (<a
href="https://redirect.github.com/getsentry/sentry-rust/pull/925">#925</a>).
This change ensures that as much data as possible remains available for
debugging.
<ul>
<li>If you notice any new issues being created for existing errors after
this change, please open an issue on <a
href="https://github.com/getsentry/sentry-rust/issues/new/choose">GitHub</a>.</li>
</ul>
</li>
</ul>
<h3>Fixes</h3>
<ul>
<li>fix: adjust sentry.origin for log integration (<a
href="https://redirect.github.com/getsentry/sentry-rust/pull/919">#919</a>)
by <a href="https://github.com/lcian"><code>@lcian</code></a></li>
</ul>
<h2>0.45.0</h2>
<h3>Breaking changes</h3>
<ul>
<li>Add custom variant to <code>AttachmentType</code> that holds an
arbitrary String. (<a
href="https://redirect.github.com/getsentry/sentry-rust/pull/916">#916</a>)</li>
</ul>
<h2>0.44.0</h2>
<h3>Breaking changes</h3>
<ul>
<li>feat(log): support combined LogFilters and RecordMappings (<a
href="https://redirect.github.com/getsentry/sentry-rust/pull/914">#914</a>)
by <a href="https://github.com/lcian"><code>@lcian</code></a>
<ul>
<li>Breaking change: <code>sentry::integrations::log::LogFilter</code>
has been changed to a <code>bitflags</code> struct.</li>
<li>It's now possible to map a <code>log</code> record to multiple items
in Sentry by combining multiple log filters in the filter, e.g.
<code>log::Level::ERROR => LogFilter::Event |
LogFilter::Log</code>.</li>
<li>If using a custom <code>mapper</code> instead, it's possible to
return a
<code>Vec<sentry::integrations::log::RecordMapping></code> to map
a <code>log</code> record to multiple items in Sentry.</li>
</ul>
</li>
</ul>
<h3>Behavioral changes</h3>
<ul>
<li>ref(log): send logs by default when logs feature flag is enabled (<a
href="https://redirect.github.com/getsentry/sentry-rust/pull/915">#915</a>)
by <a href="https://github.com/lcian"><code>@lcian</code></a>
<ul>
<li>If the <code>logs</code> feature flag is enabled, the default Sentry
<code>log</code> logger now sends logs for all events at or above
INFO.</li>
</ul>
</li>
<li>ref(logs): enable logs by default if logs feature flag is used (<a
href="https://redirect.github.com/getsentry/sentry-rust/pull/910">#910</a>)
by <a href="https://github.com/lcian"><code>@lcian</code></a>
<ul>
<li>This changes the default value of
<code>sentry::ClientOptions::enable_logs</code> to
<code>true</code>.</li>
<li>This simplifies the setup of Sentry structured logs by requiring
users to just add the <code>log</code> feature flag to the
<code>sentry</code> dependency to opt-in to sending logs.</li>
<li>When the <code>log</code> feature flag is enabled, the
<code>tracing</code> and <code>log</code> integrations will send
structured logs to Sentry for all logs/events at or above INFO level by
default.</li>
</ul>
</li>
</ul>
<h2>0.43.0</h2>
<h3>Breaking changes</h3>
<ul>
<li>ref(tracing): rework tracing to Sentry span name/op conversion (<a
href="https://redirect.github.com/getsentry/sentry-rust/pull/887">#887</a>)
by <a href="https://github.com/lcian"><code>@lcian</code></a>
<ul>
<li>The <code>tracing</code> integration now uses the tracing span name
as the Sentry span name by default.</li>
<li>Before this change, the span name would be set based on the
<code>tracing</code> span target
(<code><module>::<function></code> when using the
<code>tracing::instrument</code> macro).</li>
<li>The <code>tracing</code> integration now uses <code><span
target>::<span name></code> as the default Sentry span op (i.e.
<code><module>::<function></code> when using
<code>tracing::instrument</code>).</li>
<li>Before this change, the span op would be set based on the
<code>tracing</code> span name.</li>
<li>Read below to learn how to customize the span name and op.</li>
</ul>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/getsentry/sentry-rust/commit/8d82bfde5944de48482e4d8ada2d2ab35978845f"><code>8d82bfd</code></a>
release: 0.46.0</li>
<li><a
href="https://github.com/getsentry/sentry-rust/commit/9525735e5cdfa25c98667aa91c3cade2ef5acdff"><code>9525735</code></a>
feat(backtrace): Stop truncating backtraces (<a
href="https://redirect.github.com/getsentry/sentry-rust/issues/925">#925</a>)</li>
<li><a
href="https://github.com/getsentry/sentry-rust/commit/a57b91c5c8992c0955f22cb26f0db0625c1aa9cd"><code>a57b91c</code></a>
ref: Fix new Clippy lints (<a
href="https://redirect.github.com/getsentry/sentry-rust/issues/935">#935</a>)</li>
<li><a
href="https://github.com/getsentry/sentry-rust/commit/57595753d6d7c039b640405a369d8b039455633c"><code>5759575</code></a>
meta: Update cargo metadata (<a
href="https://redirect.github.com/getsentry/sentry-rust/issues/927">#927</a>)</li>
<li><a
href="https://github.com/getsentry/sentry-rust/commit/77193f81e44500662acd115ed190dec4bb870852"><code>77193f8</code></a>
chore: X handle update (<a
href="https://redirect.github.com/getsentry/sentry-rust/issues/926">#926</a>)</li>
<li><a
href="https://github.com/getsentry/sentry-rust/commit/ca232686f4f338f3e13a0123b15654c32c68d47c"><code>ca23268</code></a>
chore(ci): Migrate danger workflow from v2 to v3 (<a
href="https://redirect.github.com/getsentry/sentry-rust/issues/918">#918</a>)</li>
<li><a
href="https://github.com/getsentry/sentry-rust/commit/2edf6d7a54dde2284b8954501beea311a2468aae"><code>2edf6d7</code></a>
fix: adjust sentry.origin for log integration (<a
href="https://redirect.github.com/getsentry/sentry-rust/issues/919">#919</a>)</li>
<li><a
href="https://github.com/getsentry/sentry-rust/commit/641204891076a8a4efdde9fb753a2012702e58ac"><code>6412048</code></a>
Merge branch 'release/0.45.0'</li>
<li><a
href="https://github.com/getsentry/sentry-rust/commit/aa6d85b90fc8dcc1292b9727c32350e1aa12a425"><code>aa6d85b</code></a>
release: 0.45.0</li>
<li><a
href="https://github.com/getsentry/sentry-rust/commit/b99eb46bcff33ea17b309f772e0bef0db30c0bed"><code>b99eb46</code></a>
feat(types): Add custom variant to <code>AttachmentType</code> (<a
href="https://redirect.github.com/getsentry/sentry-rust/issues/916">#916</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/getsentry/sentry-rust/compare/0.34.0...0.46.0">compare
view</a></li>
</ul>
</details>
<br />
[](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>
2025-12-14 22:31:55 -08:00
|
|
|
sentry = "0.46.0"
|
2025-09-22 18:47:01 +02:00
|
|
|
serde = "1"
|
|
|
|
|
serde_json = "1"
|
2026-01-23 20:11:09 -08:00
|
|
|
serde_path_to_error = "0.1.20"
|
2026-03-04 18:08:26 -07:00
|
|
|
serde_with = "3.17"
|
2025-12-05 12:09:43 -08:00
|
|
|
serde_yaml = "0.9"
|
2025-10-03 10:43:12 -07:00
|
|
|
serial_test = "3.2.0"
|
2025-09-22 18:47:01 +02:00
|
|
|
sha1 = "0.10.6"
|
|
|
|
|
sha2 = "0.10"
|
|
|
|
|
shlex = "1.3.0"
|
|
|
|
|
similar = "2.7.0"
|
2025-12-14 22:15:58 -08:00
|
|
|
socket2 = "0.6.1"
|
2026-02-11 10:02:49 -08:00
|
|
|
sqlx = { version = "0.8.6", default-features = false, features = [
|
|
|
|
|
"chrono",
|
|
|
|
|
"json",
|
|
|
|
|
"macros",
|
|
|
|
|
"migrate",
|
|
|
|
|
"runtime-tokio-rustls",
|
|
|
|
|
"sqlite",
|
|
|
|
|
"time",
|
|
|
|
|
"uuid",
|
|
|
|
|
] }
|
2025-09-22 18:47:01 +02:00
|
|
|
starlark = "0.13.0"
|
|
|
|
|
strum = "0.27.2"
|
chore(deps): bump strum_macros from 0.27.2 to 0.28.0 in /codex-rs (#13210)
Bumps [strum_macros](https://github.com/Peternator7/strum) from 0.27.2
to 0.28.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/Peternator7/strum/blob/master/CHANGELOG.md">strum_macros's
changelog</a>.</em></p>
<blockquote>
<h2>0.28.0</h2>
<ul>
<li>
<p><a
href="https://redirect.github.com/Peternator7/strum/pull/461">#461</a>:
Allow any kind of passthrough attributes on
<code>EnumDiscriminants</code>.</p>
<ul>
<li>Previously only list-style attributes (e.g.
<code>#[strum_discriminants(derive(...))]</code>) were supported. Now
path-only
(e.g. <code>#[strum_discriminants(non_exhaustive)]</code>) and
name/value (e.g. <code>#[strum_discriminants(doc =
"foo")]</code>)
attributes are also supported.</li>
</ul>
</li>
<li>
<p><a
href="https://redirect.github.com/Peternator7/strum/pull/462">#462</a>:
Add missing <code>#[automatically_derived]</code> to generated impls not
covered by <a
href="https://redirect.github.com/Peternator7/strum/pull/444">#444</a>.</p>
</li>
<li>
<p><a
href="https://redirect.github.com/Peternator7/strum/pull/466">#466</a>:
Bump MSRV to 1.71, required to keep up with updated <code>syn</code> and
<code>windows-sys</code> dependencies. This is a breaking change if
you're on an old version of rust.</p>
</li>
<li>
<p><a
href="https://redirect.github.com/Peternator7/strum/pull/469">#469</a>:
Use absolute paths in generated proc macro code to avoid
potential name conflicts.</p>
</li>
<li>
<p><a
href="https://redirect.github.com/Peternator7/strum/pull/465">#465</a>:
Upgrade <code>phf</code> dependency to v0.13.</p>
</li>
<li>
<p><a
href="https://redirect.github.com/Peternator7/strum/pull/473">#473</a>:
Fix <code>cargo fmt</code> / <code>clippy</code> issues and add GitHub
Actions CI.</p>
</li>
<li>
<p><a
href="https://redirect.github.com/Peternator7/strum/pull/477">#477</a>:
<code>strum::ParseError</code> now implements
<code>core::fmt::Display</code> instead
<code>std::fmt::Display</code> to make it <code>#[no_std]</code>
compatible. Note the <code>Error</code> trait wasn't available in core
until <code>1.81</code>
so <code>strum::ParseError</code> still only implements that in std.</p>
</li>
<li>
<p><a
href="https://redirect.github.com/Peternator7/strum/pull/476">#476</a>:
<strong>Breaking Change</strong> - <code>EnumString</code> now
implements <code>From<&str></code>
(infallible) instead of <code>TryFrom<&str></code> when the
enum has a <code>#[strum(default)]</code> variant. This more accurately
reflects that parsing cannot fail in that case. If you need the old
<code>TryFrom</code> behavior, you can opt back in using
<code>parse_error_ty</code> and <code>parse_error_fn</code>:</p>
<pre lang="rust"><code>#[derive(EnumString)]
#[strum(parse_error_ty = strum::ParseError, parse_error_fn =
make_error)]
pub enum Color {
Red,
#[strum(default)]
Other(String),
}
<p>fn make_error(x: &str) -> strum::ParseError {
strum::ParseError::VariantNotFound
}
</code></pre></p>
</li>
<li>
<p><a
href="https://redirect.github.com/Peternator7/strum/pull/431">#431</a>:
Fix bug where <code>EnumString</code> ignored the
<code>parse_err_ty</code>
attribute when the enum had a <code>#[strum(default)]</code>
variant.</p>
</li>
<li>
<p><a
href="https://redirect.github.com/Peternator7/strum/pull/474">#474</a>:
EnumDiscriminants will now copy <code>default</code> over from the
original enum to the Discriminant enum.</p>
<pre lang="rust"><code>#[derive(Debug, Default, EnumDiscriminants)]
#[strum_discriminants(derive(Default))] // <- Remove this in 0.28.
enum MyEnum {
#[default] // <- Will be the #[default] on the MyEnumDiscriminant
#[strum_discriminants(default)] // <- Remove this in 0.28
Variant0,
Variant1 { a: NonDefault },
}
</code></pre>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/Peternator7/strum/commit/7376771128834d28bb9beba5c39846cba62e71ec"><code>7376771</code></a>
Peternator7/0.28 (<a
href="https://redirect.github.com/Peternator7/strum/issues/475">#475</a>)</li>
<li><a
href="https://github.com/Peternator7/strum/commit/26e63cd964a2e364331a5dd977d589bb9f649d8c"><code>26e63cd</code></a>
Display exists in core (<a
href="https://redirect.github.com/Peternator7/strum/issues/477">#477</a>)</li>
<li><a
href="https://github.com/Peternator7/strum/commit/9334c728eedaa8a992d1388a8f4564bbccad1934"><code>9334c72</code></a>
Make TryFrom and FromStr infallible if there's a default (<a
href="https://redirect.github.com/Peternator7/strum/issues/476">#476</a>)</li>
<li><a
href="https://github.com/Peternator7/strum/commit/0ccbbf823c16e827afc263182cd55e99e3b2a52e"><code>0ccbbf8</code></a>
Honor parse_err_ty attribute when the enum has a default variant (<a
href="https://redirect.github.com/Peternator7/strum/issues/431">#431</a>)</li>
<li><a
href="https://github.com/Peternator7/strum/commit/2c9e5a9259189ce8397f2f4967060240c6bafd74"><code>2c9e5a9</code></a>
Automatically add Default implementation to EnumDiscriminant if it
exists on ...</li>
<li><a
href="https://github.com/Peternator7/strum/commit/e241243e48359b8b811b8eaccdcfa1ae87138e0d"><code>e241243</code></a>
Fix existing cargo fmt + clippy issues and add GH actions (<a
href="https://redirect.github.com/Peternator7/strum/issues/473">#473</a>)</li>
<li><a
href="https://github.com/Peternator7/strum/commit/639b67fefd20eaead1c5d2ea794e9afe70a00312"><code>639b67f</code></a>
feat: allow any kind of passthrough attributes on
<code>EnumDiscriminants</code> (<a
href="https://redirect.github.com/Peternator7/strum/issues/461">#461</a>)</li>
<li><a
href="https://github.com/Peternator7/strum/commit/0ea1e2d0fd1460e7492ea32e6b460394d9199ff8"><code>0ea1e2d</code></a>
docs: Fix typo (<a
href="https://redirect.github.com/Peternator7/strum/issues/463">#463</a>)</li>
<li><a
href="https://github.com/Peternator7/strum/commit/36c051b91086b37d531c63ccf5a49266832a846d"><code>36c051b</code></a>
Upgrade <code>phf</code> to v0.13 (<a
href="https://redirect.github.com/Peternator7/strum/issues/465">#465</a>)</li>
<li><a
href="https://github.com/Peternator7/strum/commit/9328b38617dc6f4a3bc5fdac03883d3fc766cf34"><code>9328b38</code></a>
Use absolute paths in proc macro (<a
href="https://redirect.github.com/Peternator7/strum/issues/469">#469</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/Peternator7/strum/compare/v0.27.2...v0.28.0">compare
view</a></li>
</ul>
</details>
<br />
[](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 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>
Co-authored-by: Eric Traut <etraut@openai.com>
2026-03-04 17:58:58 -07:00
|
|
|
strum_macros = "0.28.0"
|
2025-09-22 18:47:01 +02:00
|
|
|
supports-color = "3.0.2"
|
2026-02-26 08:39:24 -08:00
|
|
|
syntect = "5"
|
2025-09-22 18:47:01 +02:00
|
|
|
sys-locale = "0.3.2"
|
2025-09-23 23:41:35 -07:00
|
|
|
tempfile = "3.23.0"
|
2026-03-04 20:22:34 +00:00
|
|
|
tar = "0.4.44"
|
2025-12-22 08:34:39 -07:00
|
|
|
test-log = "0.2.19"
|
2025-09-22 18:47:01 +02:00
|
|
|
textwrap = "0.16.2"
|
2025-10-30 19:00:00 -07:00
|
|
|
thiserror = "2.0.17"
|
2026-02-06 12:10:07 +01:00
|
|
|
time = "0.3.47"
|
2025-09-22 18:47:01 +02:00
|
|
|
tiny_http = "0.12"
|
|
|
|
|
tokio = "1"
|
2026-01-04 23:50:37 -07:00
|
|
|
tokio-stream = "0.1.18"
|
2025-09-22 18:47:01 +02:00
|
|
|
tokio-test = "0.4"
|
2026-02-11 10:02:49 -08:00
|
|
|
tokio-tungstenite = { version = "0.28.0", features = [
|
|
|
|
|
"proxy",
|
|
|
|
|
"rustls-tls-native-roots",
|
|
|
|
|
] }
|
2026-01-12 10:14:42 -08:00
|
|
|
tokio-util = "0.7.18"
|
2025-09-22 18:47:01 +02:00
|
|
|
toml = "0.9.5"
|
2025-12-29 21:07:14 -07:00
|
|
|
toml_edit = "0.24.0"
|
2026-01-26 15:48:45 -08:00
|
|
|
tracing = "0.1.44"
|
2025-09-22 18:47:01 +02:00
|
|
|
tracing-appender = "0.2.3"
|
2026-02-11 10:02:49 -08:00
|
|
|
tracing-opentelemetry = "0.32.0"
|
2025-12-29 21:07:38 -07:00
|
|
|
tracing-subscriber = "0.3.22"
|
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>
2025-09-29 19:30:55 +01:00
|
|
|
tracing-test = "0.2.5"
|
2025-10-07 16:20:12 -07:00
|
|
|
tree-sitter = "0.25.10"
|
|
|
|
|
tree-sitter-bash = "0.25"
|
2025-09-22 18:47:01 +02:00
|
|
|
ts-rs = "11"
|
2026-02-11 10:02:49 -08:00
|
|
|
tungstenite = { version = "0.27.0", features = ["deflate", "proxy"] }
|
2025-10-19 21:12:45 -07:00
|
|
|
uds_windows = "1.1.0"
|
2025-09-22 18:47:01 +02:00
|
|
|
unicode-segmentation = "1.12.0"
|
2025-09-24 16:33:46 +00:00
|
|
|
unicode-width = "0.2"
|
2025-09-22 18:47:01 +02:00
|
|
|
url = "2"
|
|
|
|
|
urlencoding = "2.1"
|
|
|
|
|
uuid = "1"
|
|
|
|
|
vt100 = "0.16.2"
|
|
|
|
|
walkdir = "2.5.0"
|
|
|
|
|
webbrowser = "1.0"
|
chore(deps): bump which from 6.0.3 to 8.0.0 in /codex-rs (#9074)
Bumps [which](https://github.com/harryfei/which-rs) from 6.0.3 to 8.0.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/harryfei/which-rs/releases">which's
releases</a>.</em></p>
<blockquote>
<h2>8.0.0</h2>
<h2>What's Changed</h2>
<ul>
<li>Add new <code>Sys</code> trait to allow abstracting over the
underlying filesystem. Particularly useful for
<code>wasm32-unknown-unknown</code> targets. Thanks <a
href="https://github.com/dsherret"><code>@dsherret</code></a> for this
contribution to which!</li>
<li>Add more debug level tracing for otherwise silent I/O errors.</li>
<li>Call the <code>NonFatalHandler</code> in more places to catch
previously ignored I/O errors.</li>
<li>Remove use of the <code>either</code> dependency.</li>
</ul>
<h2>New Contributors</h2>
<ul>
<li><a href="https://github.com/dsherret"><code>@dsherret</code></a>
made their first contribution in <a
href="https://redirect.github.com/harryfei/which-rs/pull/109">harryfei/which-rs#109</a></li>
</ul>
<h2>7.0.3</h2>
<ul>
<li>Update rustix to version 1.0. Congrats to rustix on this milestone,
and thanks <a href="https://github.com/mhils"><code>@mhils</code></a>
for this contribution to which!</li>
</ul>
<h2>7.0.2</h2>
<ul>
<li>Don't return paths containing the single dot <code>.</code>
reference to the current directory, even if the original request was
given in terms of the current directory. Thanks <a
href="https://github.com/jakobhellermann"><code>@jakobhellermann</code></a>
for this contribution!</li>
</ul>
<h2>7.0.1</h2>
<h2>What's Changed</h2>
<ul>
<li>Switch to <code>env_home</code> crate by <a
href="https://github.com/micolous"><code>@micolous</code></a> in <a
href="https://redirect.github.com/harryfei/which-rs/pull/105">harryfei/which-rs#105</a></li>
<li>fixes <a
href="https://redirect.github.com/harryfei/which-rs/issues/106">#106</a>,
bump patch version by <a
href="https://github.com/Xaeroxe"><code>@Xaeroxe</code></a> in <a
href="https://redirect.github.com/harryfei/which-rs/pull/107">harryfei/which-rs#107</a></li>
</ul>
<h2>New Contributors</h2>
<ul>
<li><a href="https://github.com/micolous"><code>@micolous</code></a>
made their first contribution in <a
href="https://redirect.github.com/harryfei/which-rs/pull/105">harryfei/which-rs#105</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/harryfei/which-rs/compare/7.0.0...7.0.1">https://github.com/harryfei/which-rs/compare/7.0.0...7.0.1</a></p>
<h2>7.0.0</h2>
<ul>
<li>Add support to <code>WhichConfig</code> for a user provided closure
that will be called whenever a nonfatal error occurs.
This technically breaks a few APIs due to the need to add more generics
and lifetimes. Most code will compile
without changes.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/harryfei/which-rs/blob/master/CHANGELOG.md">which's
changelog</a>.</em></p>
<blockquote>
<h2>8.0.0</h2>
<ul>
<li>Add new <code>Sys</code> trait to allow abstracting over the
underlying filesystem. Particularly useful for
<code>wasm32-unknown-unknown</code> targets. Thanks <a
href="https://github.com/dsherret"><code>@dsherret</code></a> for this
contribution to which!</li>
<li>Add more debug level tracing for otherwise silent I/O errors.</li>
<li>Call the <code>NonFatalHandler</code> in more places to catch
previously ignored I/O errors.</li>
<li>Remove use of the <code>either</code> dependency.</li>
</ul>
<h2>7.0.3</h2>
<ul>
<li>Update rustix to version 1.0. Congrats to rustix on this milestone,
and thanks <a href="https://github.com/mhils"><code>@mhils</code></a>
for this contribution to which!</li>
</ul>
<h2>7.0.2</h2>
<ul>
<li>Don't return paths containing the single dot <code>.</code>
reference to the current directory, even if the original request was
given in
terms of the current directory. Thanks <a
href="https://github.com/jakobhellermann"><code>@jakobhellermann</code></a>
for this contribution!</li>
</ul>
<h2>7.0.1</h2>
<ul>
<li>Get user home directory from <code>env_home</code> instead of
<code>home</code>. Thanks <a
href="https://github.com/micolous"><code>@micolous</code></a> for this
contribution!</li>
<li>If home directory is unavailable, do not expand the tilde to an
empty string. Leave it as is.</li>
</ul>
<h2>7.0.0</h2>
<ul>
<li>Add support to <code>WhichConfig</code> for a user provided closure
that will be called whenever a nonfatal error occurs.
This technically breaks a few APIs due to the need to add more generics
and lifetimes. Most code will compile
without changes.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/harryfei/which-rs/commit/adac2cdae7eaef4d5ce4cb2984ba43a0559adf06"><code>adac2cd</code></a>
bump version, update changelog</li>
<li><a
href="https://github.com/harryfei/which-rs/commit/84e152ec23f3471eeefb278a55f8fdb818088866"><code>84e152e</code></a>
reduce sys::Sys requirements, add some tracing for otherwise silent
errors (#...</li>
<li><a
href="https://github.com/harryfei/which-rs/commit/a0a6daf199c15b0d2af07b91b0cb2f3054727311"><code>a0a6daf</code></a>
feat: add Sys trait for swapping out system (<a
href="https://redirect.github.com/harryfei/which-rs/issues/109">#109</a>)</li>
<li><a
href="https://github.com/harryfei/which-rs/commit/eef199824a0cf1596e8afbe9e7a5e6a793486cad"><code>eef1998</code></a>
Add actively maintained badge</li>
<li><a
href="https://github.com/harryfei/which-rs/commit/1d145deef8aaaa1a493a9f33fbb7b7031233284e"><code>1d145de</code></a>
release version 7.0.3</li>
<li><a
href="https://github.com/harryfei/which-rs/commit/f5e529223445cdd0fa9a9c190a92276d7de4eb32"><code>f5e5292</code></a>
fix unrelated lint error</li>
<li><a
href="https://github.com/harryfei/which-rs/commit/4dcefa6fe96f8cd87e1dcdc23146a5d404277cd6"><code>4dcefa6</code></a>
bump rustix</li>
<li><a
href="https://github.com/harryfei/which-rs/commit/bd868818bdb55923acfd2a63468335f6600a6cf9"><code>bd86881</code></a>
bump version, add to changelog</li>
<li><a
href="https://github.com/harryfei/which-rs/commit/cf37760ea1840a87d69d5eb18fc56a5b871e6d53"><code>cf37760</code></a>
don't run relative dot test on macos</li>
<li><a
href="https://github.com/harryfei/which-rs/commit/f2c4bd6e8be4c74006b303108aeb4977fbe684e2"><code>f2c4bd6</code></a>
update target to new name for wasm32-wasip1</li>
<li>Additional commits viewable in <a
href="https://github.com/harryfei/which-rs/compare/6.0.3...8.0.0">compare
view</a></li>
</ul>
</details>
<br />
[](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>
2026-01-12 10:14:00 -08:00
|
|
|
which = "8"
|
2025-12-08 17:13:51 +00:00
|
|
|
wildmatch = "2.6.1"
|
2026-02-03 14:09:37 -08:00
|
|
|
zip = "2.4.2"
|
2026-02-11 10:02:49 -08:00
|
|
|
zstd = "0.13"
|
Windows Sandbox - Alpha version (#4905)
- Added the new codex-windows-sandbox crate that builds both a library
entry point (run_windows_sandbox_capture) and a CLI executable to launch
commands inside a Windows restricted-token sandbox, including ACL
management, capability SID provisioning, network lockdown, and output
capture
(windows-sandbox-rs/src/lib.rs:167, windows-sandbox-rs/src/main.rs:54).
- Introduced the experimental WindowsSandbox feature flag and wiring so
Windows builds can opt into the sandbox:
SandboxType::WindowsRestrictedToken, the in-process execution path, and
platform sandbox selection now honor the flag (core/src/features.rs:47,
core/src/config.rs:1224, core/src/safety.rs:19,
core/src/sandboxing/mod.rs:69, core/src/exec.rs:79,
core/src/exec.rs:172).
- Updated workspace metadata to include the new crate and its
Windows-specific dependencies so the core crate can link against it
(codex-rs/
Cargo.toml:91, core/Cargo.toml:86).
- Added a PowerShell bootstrap script that installs the Windows
toolchain, required CLI utilities, and builds the workspace to ease
development
on the platform (scripts/setup-windows.ps1:1).
- Landed a Python smoke-test suite that exercises
read-only/workspace-write policies, ACL behavior, and network denial for
the Windows sandbox
binary (windows-sandbox-rs/sandbox_smoketests.py:1).
2025-10-30 15:51:57 -07:00
|
|
|
|
2025-09-22 18:47:01 +02:00
|
|
|
wiremock = "0.6"
|
2025-11-09 22:03:36 -08:00
|
|
|
zeroize = "1.8.2"
|
2025-09-22 18:47:01 +02:00
|
|
|
|
2025-05-08 09:46:18 -07:00
|
|
|
[workspace.lints]
|
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.
2025-05-23 11:37:07 -07:00
|
|
|
rust = {}
|
2025-05-08 09:46:18 -07:00
|
|
|
|
|
|
|
|
[workspace.lints.clippy]
|
2025-05-12 08:45:46 -07:00
|
|
|
expect_used = "deny"
|
2025-09-22 19:16:02 +02:00
|
|
|
identity_op = "deny"
|
|
|
|
|
manual_clamp = "deny"
|
|
|
|
|
manual_filter = "deny"
|
|
|
|
|
manual_find = "deny"
|
|
|
|
|
manual_flatten = "deny"
|
|
|
|
|
manual_map = "deny"
|
|
|
|
|
manual_memcpy = "deny"
|
|
|
|
|
manual_non_exhaustive = "deny"
|
|
|
|
|
manual_ok_or = "deny"
|
|
|
|
|
manual_range_contains = "deny"
|
|
|
|
|
manual_retain = "deny"
|
|
|
|
|
manual_strip = "deny"
|
|
|
|
|
manual_try_fold = "deny"
|
|
|
|
|
manual_unwrap_or = "deny"
|
|
|
|
|
needless_borrow = "deny"
|
|
|
|
|
needless_borrowed_reference = "deny"
|
|
|
|
|
needless_collect = "deny"
|
|
|
|
|
needless_late_init = "deny"
|
|
|
|
|
needless_option_as_deref = "deny"
|
|
|
|
|
needless_question_mark = "deny"
|
|
|
|
|
needless_update = "deny"
|
2025-09-11 11:59:37 -07:00
|
|
|
redundant_clone = "deny"
|
2025-09-22 20:30:16 +01:00
|
|
|
redundant_closure = "deny"
|
|
|
|
|
redundant_closure_for_method_calls = "deny"
|
2025-09-22 19:16:02 +02:00
|
|
|
redundant_static_lifetimes = "deny"
|
|
|
|
|
trivially_copy_pass_by_ref = "deny"
|
2025-08-28 11:25:23 -07:00
|
|
|
uninlined_format_args = "deny"
|
2025-09-22 19:16:02 +02:00
|
|
|
unnecessary_filter_map = "deny"
|
|
|
|
|
unnecessary_lazy_evaluations = "deny"
|
|
|
|
|
unnecessary_sort_by = "deny"
|
|
|
|
|
unnecessary_to_owned = "deny"
|
2025-05-08 09:46:18 -07:00
|
|
|
unwrap_used = "deny"
|
|
|
|
|
|
2025-09-22 18:47:01 +02:00
|
|
|
# cargo-shear cannot see the platform-specific openssl-sys usage, so we
|
|
|
|
|
# silence the false positive here instead of deleting a real dependency.
|
|
|
|
|
[workspace.metadata.cargo-shear]
|
2026-02-11 10:02:49 -08:00
|
|
|
ignored = [
|
|
|
|
|
"icu_provider",
|
|
|
|
|
"openssl-sys",
|
|
|
|
|
"codex-utils-readiness",
|
2026-03-20 12:08:25 -07:00
|
|
|
"codex-secrets",
|
Code mode on v8 (#15276)
Moves Code Mode to a new crate with no dependencies on codex. This
create encodes the code mode semantics that we want for lifetime,
mounting, tool calling.
The model-facing surface is mostly unchanged. `exec` still runs raw
JavaScript, `wait` still resumes or terminates a `cell_id`, nested tools
are still available through `tools.*`, and helpers like `text`, `image`,
`store`, `load`, `notify`, `yield_control`, and `exit` still exist.
The major change is underneath that surface:
- Old code mode was an external Node runtime.
- New code mode is an in-process V8 runtime embedded directly in Rust.
- Old code mode managed cells inside a long-lived Node runner process.
- New code mode manages cells in Rust, with one V8 runtime thread per
active `exec`.
- Old code mode used JSON protocol messages over child stdin/stdout plus
Node worker-thread messages.
- New code mode uses Rust channels and direct V8 callbacks/events.
This PR also fixes the two migration regressions that fell out of that
substrate change:
- `wait { terminate: true }` now waits for the V8 runtime to actually
stop before reporting termination.
- synchronous top-level `exit()` now succeeds again instead of surfacing
as a script error.
---
- `core/src/tools/code_mode/*` is now mostly an adapter layer for the
public `exec` / `wait` tools.
- `code-mode/src/service.rs` owns cell sessions and async control flow
in Rust.
- `code-mode/src/runtime/*.rs` owns the embedded V8 isolate and
JavaScript execution.
- each `exec` spawns a dedicated runtime thread plus a Rust
session-control task.
- helper globals are installed directly into the V8 context instead of
being injected through a source prelude.
- helper modules like `tools.js` and `@openai/code_mode` are synthesized
through V8 module resolution callbacks in Rust.
---
Also added a benchmark for showing the speed of init and use of a code
mode env:
```
$ cargo bench -p codex-code-mode --bench exec_overhead -- --samples 30 --warm-iterations 25 --tool-counts 0,32,128
Finished [`bench` profile [optimized]](https://doc.rust-lang.org/cargo/reference/profiles.html#default-profiles) target(s) in 0.18s
Running benches/exec_overhead.rs (target/release/deps/exec_overhead-008c440d800545ae)
exec_overhead: samples=30, warm_iterations=25, tool_counts=[0, 32, 128]
scenario tools samples warmups iters mean/exec p95/exec rssΔ p50 rssΔ max
cold_exec 0 30 0 1 1.13ms 1.20ms 8.05MiB 8.06MiB
warm_exec 0 30 1 25 473.43us 512.49us 912.00KiB 1.33MiB
cold_exec 32 30 0 1 1.03ms 1.15ms 8.08MiB 8.11MiB
warm_exec 32 30 1 25 509.73us 545.76us 960.00KiB 1.30MiB
cold_exec 128 30 0 1 1.14ms 1.19ms 8.30MiB 8.34MiB
warm_exec 128 30 1 25 575.08us 591.03us 736.00KiB 864.00KiB
memory uses a fresh-process max RSS delta for each scenario
```
---------
Co-authored-by: Codex <noreply@openai.com>
2026-03-20 23:36:58 -07:00
|
|
|
"codex-v8-poc",
|
2026-02-11 10:02:49 -08:00
|
|
|
]
|
2025-09-22 18:47:01 +02:00
|
|
|
|
2025-04-29 16:38:47 -07:00
|
|
|
[profile.release]
|
2025-04-29 19:21:26 -07:00
|
|
|
lto = "fat"
|
2026-02-26 08:39:24 -08:00
|
|
|
split-debuginfo = "off"
|
2025-04-29 19:21:26 -07:00
|
|
|
# Because we bundle some of these executables with the TypeScript CLI, we
|
|
|
|
|
# remove everything to make the binary as small as possible.
|
|
|
|
|
strip = "symbols"
|
2025-06-28 15:24:48 -07:00
|
|
|
|
|
|
|
|
# See https://github.com/openai/codex/issues/1411 for details.
|
|
|
|
|
codegen-units = 1
|
2025-07-28 07:45:49 -07:00
|
|
|
|
2025-10-20 14:52:37 -07:00
|
|
|
[profile.ci-test]
|
|
|
|
|
debug = 1 # Reduce debug symbol size
|
|
|
|
|
inherits = "test"
|
|
|
|
|
opt-level = 0
|
|
|
|
|
|
2025-07-28 07:45:49 -07:00
|
|
|
[patch.crates-io]
|
2025-10-03 14:15:19 -07:00
|
|
|
# Uncomment to debug local changes.
|
2025-07-28 07:45:49 -07:00
|
|
|
# ratatui = { path = "../../ratatui" }
|
2025-10-31 16:36:41 -07:00
|
|
|
crossterm = { git = "https://github.com/nornagon/crossterm", branch = "nornagon/color-query" }
|
2025-11-12 22:24:36 -08:00
|
|
|
ratatui = { git = "https://github.com/nornagon/ratatui", branch = "nornagon-v0.29.0-patch" }
|
feat: enable premessage-deflate for websockets (#10966)
note:
unfortunately, tokio-tungstenite / tungstenite upgrade triggers some
problems with linker of rama-tls-boring with openssl:
```
error: linking with `/Users/apanasenko/Library/Caches/cargo-zigbuild/0.20.1/zigcc-x86_64-unknown-linux-musl-ff6a.sh` failed: exit status: 1
|
= note: "/Users/apanasenko/Library/Caches/cargo-zigbuild/0.20.1/zigcc-x86_64-unknown-linux-musl-ff6a.sh" "-m64" "<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/rcrt1.o" "<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/crti.o" "<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/crtbeginS.o" "<1 object files omitted>" "-Wl,--as-needed" "-Wl,-Bstatic" "/var/folders/kt/52y_g75x3ng8ktvk3rfwm6400000gp/T/rustcyGQdYm/{liblzma_sys-662a82316f96ec30,libbzip2_sys-bf78a2d58d5cbce6,liblibsqlite3_sys-6c004987fd67a36a,libtree_sitter_bash-220b99a97d331ab7,libtree_sitter-858f0a1dbfea58bd,libzstd_sys-6eb237deec748c5b,libring-2a87376483bf916f,libopenssl_sys-7c189e68b37fe2bb,liblibz_sys-4344eef4345520b1,librama_boring_sys-0414e98115015ee0}.rlib" "-lc++" "-lc++abi" "-lunwind" "-lc" "<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/libcompiler_builtins-*.rlib" "-L" "/var/folders/kt/52y_g75x3ng8ktvk3rfwm6400000gp/T/rustcyGQdYm/raw-dylibs" "-Wl,-Bdynamic" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-nostartfiles" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/libz-sys-ff5ea50d88c28ffb/out/lib" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/ring-bdec3dddc19f5a5e/out" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/openssl-sys-96e0870de3ca22bc/out/openssl-build/install/lib" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/zstd-sys-0cc37a5da1481740/out" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/tree-sitter-72d2418073317c0f/out" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/tree-sitter-bash-bfd293a9f333ce6a/out" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/libsqlite3-sys-b78b2cfb81a330fc/out" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/bzip2-sys-69a145cc859ef275/out/lib" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/lzma-sys-07e92d0b6baa6fd4/out" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/rama-boring-sys-0bc2dfbf669addc4/out/build/crypto/" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/rama-boring-sys-0bc2dfbf669addc4/out/build/ssl/" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/rama-boring-sys-0bc2dfbf669addc4/out/build/" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/rama-boring-sys-0bc2dfbf669addc4/out/build" "-L" "<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained" "-L" "<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib" "-o" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/deps/codex_network_proxy-d08268b863517761" "-Wl,--gc-sections" "-static-pie" "-Wl,-z,relro,-z,now" "-Wl,-O1" "-Wl,--strip-all" "-nodefaultlibs" "<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/crtendS.o" "<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/crtn.o"
= note: some arguments are omitted. use `--verbose` to show all linker arguments
= note: warning: ignoring deprecated linker optimization setting '1'
warning: unable to open library directory '/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/rama-boring-sys-0bc2dfbf669addc4/out/build/crypto/': FileNotFound
ld.lld: error: duplicate symbol: SSL_export_keying_material
>>> defined at ssl_lib.c:3816 (ssl/ssl_lib.c:3816)
>>> libssl-lib-ssl_lib.o:(SSL_export_keying_material) in archive /var/folders/kt/52y_g75x3ng8ktvk3rfwm6400000gp/T/rustcyGQdYm/libopenssl_sys-7c189e68b37fe2bb.rlib
>>> defined at t1_enc.cc:205 (/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/rama-boring-sys-0bc2dfbf669addc4/out/boringssl/ssl/t1_enc.cc:205)
>>> t1_enc.cc.o:(.text.SSL_export_keying_material+0x0) in archive /var/folders/kt/52y_g75x3ng8ktvk3rfwm6400000gp/T/rustcyGQdYm/librama_boring_sys-0414e98115015ee0.rlib
ld.lld: error: duplicate symbol: d2i_ASN1_TIME
>>> defined at a_time.c:27 (crypto/asn1/a_time.c:27)
>>> libcrypto-lib-a_time.o:(d2i_ASN1_TIME) in archive /var/folders/kt/52y_g75x3ng8ktvk3rfwm6400000gp/T/rustcyGQdYm/libopenssl_sys-7c189e68b37fe2bb.rlib
>>> defined at a_time.cc:34 (/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/rama-boring-sys-0bc2dfbf669addc4/out/boringssl/crypto/asn1/a_time.cc:34)
>>> a_time.cc.o:(.text.d2i_ASN1_TIME+0x0) in archive /var/folders/kt/52y_g75x3ng8ktvk3rfwm6400000gp/T/rustcyGQdYm/librama_boring_sys-0414e98115015ee0.rlib
```
that force me to migrate away from rama-tls-boring to rama-tls-rustls
and pin `ring` for rustls.
2026-02-07 17:59:34 -08:00
|
|
|
tokio-tungstenite = { git = "https://github.com/openai-oss-forks/tokio-tungstenite", rev = "132f5b39c862e3a970f731d709608b3e6276d5f6" }
|
|
|
|
|
tungstenite = { git = "https://github.com/openai-oss-forks/tungstenite-rs", rev = "9200079d3b54a1ff51072e24d81fd354f085156f" }
|
2025-10-03 14:15:19 -07:00
|
|
|
|
|
|
|
|
# Uncomment to debug local changes.
|
|
|
|
|
# rmcp = { path = "../../rust-sdk/crates/rmcp" }
|
2026-01-22 15:23:15 -08:00
|
|
|
|
feat: enable premessage-deflate for websockets (#10966)
note:
unfortunately, tokio-tungstenite / tungstenite upgrade triggers some
problems with linker of rama-tls-boring with openssl:
```
error: linking with `/Users/apanasenko/Library/Caches/cargo-zigbuild/0.20.1/zigcc-x86_64-unknown-linux-musl-ff6a.sh` failed: exit status: 1
|
= note: "/Users/apanasenko/Library/Caches/cargo-zigbuild/0.20.1/zigcc-x86_64-unknown-linux-musl-ff6a.sh" "-m64" "<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/rcrt1.o" "<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/crti.o" "<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/crtbeginS.o" "<1 object files omitted>" "-Wl,--as-needed" "-Wl,-Bstatic" "/var/folders/kt/52y_g75x3ng8ktvk3rfwm6400000gp/T/rustcyGQdYm/{liblzma_sys-662a82316f96ec30,libbzip2_sys-bf78a2d58d5cbce6,liblibsqlite3_sys-6c004987fd67a36a,libtree_sitter_bash-220b99a97d331ab7,libtree_sitter-858f0a1dbfea58bd,libzstd_sys-6eb237deec748c5b,libring-2a87376483bf916f,libopenssl_sys-7c189e68b37fe2bb,liblibz_sys-4344eef4345520b1,librama_boring_sys-0414e98115015ee0}.rlib" "-lc++" "-lc++abi" "-lunwind" "-lc" "<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/libcompiler_builtins-*.rlib" "-L" "/var/folders/kt/52y_g75x3ng8ktvk3rfwm6400000gp/T/rustcyGQdYm/raw-dylibs" "-Wl,-Bdynamic" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-nostartfiles" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/libz-sys-ff5ea50d88c28ffb/out/lib" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/ring-bdec3dddc19f5a5e/out" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/openssl-sys-96e0870de3ca22bc/out/openssl-build/install/lib" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/zstd-sys-0cc37a5da1481740/out" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/tree-sitter-72d2418073317c0f/out" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/tree-sitter-bash-bfd293a9f333ce6a/out" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/libsqlite3-sys-b78b2cfb81a330fc/out" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/bzip2-sys-69a145cc859ef275/out/lib" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/lzma-sys-07e92d0b6baa6fd4/out" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/rama-boring-sys-0bc2dfbf669addc4/out/build/crypto/" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/rama-boring-sys-0bc2dfbf669addc4/out/build/ssl/" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/rama-boring-sys-0bc2dfbf669addc4/out/build/" "-L" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/rama-boring-sys-0bc2dfbf669addc4/out/build" "-L" "<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained" "-L" "<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib" "-o" "/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/deps/codex_network_proxy-d08268b863517761" "-Wl,--gc-sections" "-static-pie" "-Wl,-z,relro,-z,now" "-Wl,-O1" "-Wl,--strip-all" "-nodefaultlibs" "<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/crtendS.o" "<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/crtn.o"
= note: some arguments are omitted. use `--verbose` to show all linker arguments
= note: warning: ignoring deprecated linker optimization setting '1'
warning: unable to open library directory '/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/rama-boring-sys-0bc2dfbf669addc4/out/build/crypto/': FileNotFound
ld.lld: error: duplicate symbol: SSL_export_keying_material
>>> defined at ssl_lib.c:3816 (ssl/ssl_lib.c:3816)
>>> libssl-lib-ssl_lib.o:(SSL_export_keying_material) in archive /var/folders/kt/52y_g75x3ng8ktvk3rfwm6400000gp/T/rustcyGQdYm/libopenssl_sys-7c189e68b37fe2bb.rlib
>>> defined at t1_enc.cc:205 (/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/rama-boring-sys-0bc2dfbf669addc4/out/boringssl/ssl/t1_enc.cc:205)
>>> t1_enc.cc.o:(.text.SSL_export_keying_material+0x0) in archive /var/folders/kt/52y_g75x3ng8ktvk3rfwm6400000gp/T/rustcyGQdYm/librama_boring_sys-0414e98115015ee0.rlib
ld.lld: error: duplicate symbol: d2i_ASN1_TIME
>>> defined at a_time.c:27 (crypto/asn1/a_time.c:27)
>>> libcrypto-lib-a_time.o:(d2i_ASN1_TIME) in archive /var/folders/kt/52y_g75x3ng8ktvk3rfwm6400000gp/T/rustcyGQdYm/libopenssl_sys-7c189e68b37fe2bb.rlib
>>> defined at a_time.cc:34 (/Users/apanasenko/code/codex/codex-rs/target/x86_64-unknown-linux-musl/release/build/rama-boring-sys-0bc2dfbf669addc4/out/boringssl/crypto/asn1/a_time.cc:34)
>>> a_time.cc.o:(.text.d2i_ASN1_TIME+0x0) in archive /var/folders/kt/52y_g75x3ng8ktvk3rfwm6400000gp/T/rustcyGQdYm/librama_boring_sys-0414e98115015ee0.rlib
```
that force me to migrate away from rama-tls-boring to rama-tls-rustls
and pin `ring` for rustls.
2026-02-07 17:59:34 -08:00
|
|
|
[patch."ssh://git@github.com/openai-oss-forks/tungstenite-rs.git"]
|
|
|
|
|
tungstenite = { git = "https://github.com/openai-oss-forks/tungstenite-rs", rev = "9200079d3b54a1ff51072e24d81fd354f085156f" }
|