valknar/llmx
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
d1de7bb383552e8fadd94be79d65d188e00fd562
llmx/codex-rs/Cargo.toml

37 lines
771 B
TOML
Raw Normal View History

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]
resolver = "2"
members = [
"ansi-escape",
"apply-patch",
"cli",
chore: introduce codex-common crate (#843) I started this PR because I wanted to share the `format_duration()` utility function in `codex-rs/exec/src/event_processor.rs` with the TUI. The question was: where to put it? `core` should have as few dependencies as possible, so moving it there would introduce a dependency on `chrono`, which seemed undesirable. `core` already had this `cli` feature to deal with a similar situation around sharing common utility functions, so I decided to: * make `core` feature-free * introduce `common` * `common` can have as many "special interest" features as it needs, each of which can declare their own deps * the first two features of common are `cli` and `elapsed` In practice, this meant updating a number of `Cargo.toml` files, replacing this line: ```toml codex-core = { path = "../core", features = ["cli"] } ``` with these: ```toml codex-core = { path = "../core" } codex-common = { path = "../common", features = ["cli"] } ``` Moving `format_duration()` into its own file gave it some "breathing room" to add a unit test, so I had Codex generate some tests and new support for durations over 1 minute.
2025-05-06 17:38:56 -07:00
"common",
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",
"exec",
feat: introduce codex_execpolicy crate for defining "safe" commands (#634) As described in detail in `codex-rs/execpolicy/README.md` introduced in this PR, `execpolicy` is a tool that lets you define a set of _patterns_ used to match [`execv(3)`](https://linux.die.net/man/3/execv) invocations. When a pattern is matched, `execpolicy` returns the parsed version in a structured form that is amenable to static analysis. The primary use case is to define patterns match commands that should be auto-approved by a tool such as Codex. This supports a richer pattern matching mechanism that the sort of prefix-matching we have done to date, e.g.: https://github.com/openai/codex/blob/5e40d9d2211737f46136610497bcd9a8271009e0/codex-cli/src/approvals.ts#L333-L354 Note we are still playing with the API and the `system_path` option in particular still needs some work.
2025-04-24 17:14:47 -07:00
"execpolicy",
feat: initial McpClient for Rust (#822) This PR introduces an initial `McpClient` that we will use to give Codex itself programmatic access to foreign MCPs. This does not wire it up in Codex itself yet, but the new `mcp-client` crate includes a `main.rs` for basic testing for now. Manually tested by sending a `tools/list` request to Codex's own MCP server: ``` codex-rs$ cargo build codex-rs$ cargo run --bin codex-mcp-client ./target/debug/codex-mcp-server { "tools": [ { "description": "Run a Codex session. Accepts configuration parameters matching the Codex Config struct.", "inputSchema": { "properties": { "approval-policy": { "description": "Execution approval policy expressed as the kebab-case variant name (`unless-allow-listed`, `auto-edit`, `on-failure`, `never`).", "enum": [ "auto-edit", "unless-allow-listed", "on-failure", "never" ], "type": "string" }, "cwd": { "description": "Working directory for the session. If relative, it is resolved against the server process's current working directory.", "type": "string" }, "disable-response-storage": { "description": "Disable server-side response storage.", "type": "boolean" }, "model": { "description": "Optional override for the model name (e.g. \"o3\", \"o4-mini\")", "type": "string" }, "prompt": { "description": "The *initial user prompt* to start the Codex conversation.", "type": "string" }, "sandbox-permissions": { "description": "Sandbox permissions using the same string values accepted by the CLI (e.g. \"disk-write-cwd\", \"network-full-access\").", "items": { "enum": [ "disk-full-read-access", "disk-write-cwd", "disk-write-platform-user-temp-folder", "disk-write-platform-global-temp-folder", "disk-full-write-access", "network-full-access" ], "type": "string" }, "type": "array" } }, "required": [ "prompt" ], "type": "object" }, "name": "codex" } ] } ```
2025-05-05 12:52:55 -07:00
"mcp-client",
feat: introduce mcp-server crate (#792) This introduces the `mcp-server` crate, which contains a barebones MCP server that provides an `echo` tool that echoes the user's request back to them. To test it out, I launched [modelcontextprotocol/inspector](https://github.com/modelcontextprotocol/inspector) like so: ``` mcp-server$ npx @modelcontextprotocol/inspector cargo run -- ``` and opened up `http://127.0.0.1:6274` in my browser: ![image](https://github.com/user-attachments/assets/83fc55d4-25c2-4497-80cd-e9702283ff93) I also had to make a small fix to `mcp-types`, adding `#[serde(untagged)]` to a number of `enum`s.
2025-05-02 17:25:58 -07:00
"mcp-server",
feat: introduce mcp-types crate (#787) This adds our own `mcp-types` crate to our Cargo workspace. We vendor in the [`2025-03-26/schema.json`](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/05f204513641c05bd78d056791af99c6c84520fa/schema/2025-03-26/schema.json) from the MCP repo and introduce a `generate_mcp_types.py` script to codegen the `lib.rs` from the JSON schema. Test coverage is currently light, but I plan to refine things as we start making use of this crate. And yes, I am aware that https://github.com/modelcontextprotocol/rust-sdk exists, though the published https://crates.io/crates/rmcp appears to be a competing effort. While things are up in the air, it seems better for us to control our own version of this code. Incidentally, Codex did a lot of the work for this PR. I told it to never edit `lib.rs` directly and instead to update `generate_mcp_types.py` and then re-run it to update `lib.rs`. It followed these instructions and once things were working end-to-end, I iteratively asked for changes to the tests until the API looked reasonable (and the code worked). Codex was responsible for figuring out what to do to `generate_mcp_types.py` to achieve the requested test/API changes.
2025-05-02 13:33:14 -07:00
"mcp-types",
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",
]
[codex-rs] Add rust-release action (#671) Taking a pass at building artifacts per platform so we can consider different distribution strategies that don't require users to install the full `cargo` toolchain. Right now this grabs just the `codex-repl` and `codex-tui` bins for 5 different targets and bundles them into a draft release. I think a clearly marked pre-release set of artifacts will unblock the next step of testing.
2025-04-29 16:38:47 -07:00
[workspace.package]
chore: script to create a Rust release (#759) For now, keep things simple such that we never update the `version` in the `Cargo.toml` for the workspace root on the `main` branch. Instead, create a new branch for a release, push one commit that updates the `version`, and then tag that branch to kick off a release. To test, I ran this script and created this release job: https://github.com/openai/codex/actions/runs/14762580641
2025-04-30 12:39:03 -07:00
version = "0.0.0"
Update cargo to 2024 edition (#842) Some effects of this change: - New formatting changes across many files. No functionality changes should occur from that. - Calls to `set_env` are considered unsafe, since this only happens in tests we wrap them in `unsafe` blocks
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"
[codex-rs] Add rust-release action (#671) Taking a pass at building artifacts per platform so we can consider different distribution strategies that don't require users to install the full `cargo` toolchain. Right now this grabs just the `codex-repl` and `codex-tui` bins for 5 different targets and bundles them into a draft release. I think a clearly marked pre-release set of artifacts will unblock the next step of testing.
2025-04-29 16:38:47 -07:00
Workspace lints and disallow unwrap (#855) Sets submodules to use workspace lints. Added denying unwrap as a workspace level lint, which found a couple of cases where we could have propagated errors. Also manually labeled ones that were fine by my eye.
2025-05-08 09:46:18 -07:00
[workspace.lints]
rust = { }
[workspace.lints.clippy]
Disallow expect via lints (#865) Adds `expect()` as a denied lint. Same deal applies with `unwrap()` where we now need to put `#[expect(...` on ones that we legit want. Took care to enable `expect()` in test contexts. # Tests ``` cargo fmt cargo clippy --all-features --all-targets --no-deps -- -D warnings cargo test ```
2025-05-12 08:45:46 -07:00
expect_used = "deny"
Workspace lints and disallow unwrap (#855) Sets submodules to use workspace lints. Added denying unwrap as a workspace level lint, which found a couple of cases where we could have propagated errors. Also manually labeled ones that were fine by my eye.
2025-05-08 09:46:18 -07:00
unwrap_used = "deny"
[codex-rs] Add rust-release action (#671) Taking a pass at building artifacts per platform so we can consider different distribution strategies that don't require users to install the full `cargo` toolchain. Right now this grabs just the `codex-repl` and `codex-tui` bins for 5 different targets and bundles them into a draft release. I think a clearly marked pre-release set of artifacts will unblock the next step of testing.
2025-04-29 16:38:47 -07:00
[profile.release]
feat: codex-linux-sandbox standalone executable (#740) This introduces a standalone executable that run the equivalent of the `codex debug landlock` subcommand and updates `rust-release.yml` to include it in the release. The idea is that we will include this small binary with the TypeScript CLI to provide support for Linux sandboxing.
2025-04-29 19:21:26 -07:00
lto = "fat"
# Because we bundle some of these executables with the TypeScript CLI, we
# remove everything to make the binary as small as possible.
strip = "symbols"
Reference in New Issue Copy Permalink