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

24 lines
419 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",
"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"
[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