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
|
|
|
[package]
|
|
|
|
|
name = "codex-cli"
|
2025-11-24 12:22:18 -08:00
|
|
|
version.workspace = true
|
|
|
|
|
edition.workspace = true
|
|
|
|
|
license.workspace = true
|
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
|
|
|
|
|
|
|
|
[[bin]]
|
|
|
|
|
name = "codex"
|
|
|
|
|
path = "src/main.rs"
|
|
|
|
|
|
2025-04-29 19:21:26 -07:00
|
|
|
[lib]
|
|
|
|
|
name = "codex_cli"
|
|
|
|
|
path = "src/lib.rs"
|
|
|
|
|
|
2025-05-08 09:46:18 -07:00
|
|
|
[lints]
|
|
|
|
|
workspace = true
|
|
|
|
|
|
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
|
|
|
[dependencies]
|
2025-09-22 18:47:01 +02:00
|
|
|
anyhow = { workspace = true }
|
|
|
|
|
clap = { workspace = true, features = ["derive"] }
|
|
|
|
|
clap_complete = { workspace = true }
|
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 = { workspace = true }
|
2025-10-19 21:12:45 -07:00
|
|
|
codex-app-server-protocol = { workspace = true }
|
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 = { workspace = true }
|
2025-09-22 18:47:01 +02:00
|
|
|
codex-arg0 = { workspace = true }
|
|
|
|
|
codex-chatgpt = { workspace = true }
|
2025-10-19 21:12:45 -07:00
|
|
|
codex-cloud-tasks = { path = "../cloud-tasks" }
|
2026-02-11 04:59:24 -08:00
|
|
|
codex-utils-cli = { workspace = true }
|
2026-02-20 23:19:29 -08:00
|
|
|
codex-config = { workspace = true }
|
2025-09-22 18:47:01 +02:00
|
|
|
codex-core = { workspace = true }
|
|
|
|
|
codex-exec = { workspace = true }
|
2025-11-20 16:44:31 -05:00
|
|
|
codex-execpolicy = { workspace = true }
|
2026-03-19 20:12:07 -07:00
|
|
|
codex-features = { workspace = true }
|
2025-09-22 18:47:01 +02:00
|
|
|
codex-login = { workspace = true }
|
|
|
|
|
codex-mcp-server = { workspace = true }
|
|
|
|
|
codex-protocol = { workspace = true }
|
2025-09-30 03:10:33 -07:00
|
|
|
codex-responses-api-proxy = { workspace = true }
|
2025-10-03 10:43:12 -07:00
|
|
|
codex-rmcp-client = { workspace = true }
|
2026-02-27 17:45:55 -08:00
|
|
|
codex-state = { workspace = true }
|
2025-10-19 21:12:45 -07:00
|
|
|
codex-stdio-to-uds = { workspace = true }
|
2026-03-19 14:08:04 -07:00
|
|
|
codex-terminal-detection = { workspace = true }
|
2025-10-19 21:12:45 -07:00
|
|
|
codex-tui = { workspace = true }
|
2026-03-16 10:49:19 -06:00
|
|
|
codex-tui-app-server = { workspace = true }
|
2025-11-10 14:48:14 -08:00
|
|
|
libc = { workspace = true }
|
2025-09-22 15:24:31 -07:00
|
|
|
owo-colors = { workspace = true }
|
2025-12-19 20:11:27 -08:00
|
|
|
regex-lite = { workspace = true }
|
2025-09-22 18:47:01 +02:00
|
|
|
serde_json = { workspace = true }
|
2025-09-22 15:24:31 -07:00
|
|
|
supports-color = { workspace = true }
|
2026-02-02 17:37:04 -08:00
|
|
|
tempfile = { workspace = true }
|
2025-09-22 18:47:01 +02:00
|
|
|
tokio = { workspace = true, features = [
|
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
|
|
|
"io-std",
|
|
|
|
|
"macros",
|
|
|
|
|
"process",
|
|
|
|
|
"rt-multi-thread",
|
|
|
|
|
"signal",
|
|
|
|
|
] }
|
2025-12-19 20:11:27 -08:00
|
|
|
toml = { workspace = true }
|
2025-11-10 14:48:14 -08:00
|
|
|
tracing = { workspace = true }
|
feat: add auth login diagnostics (#13797)
## Problem
Browser login failures historically leave support with an incomplete
picture. HARs can show that the browser completed OAuth and reached the
localhost callback, but they do not explain why the native client failed
on the final `/oauth/token` exchange. Direct `codex login` also relied
mostly on terminal stderr and the browser error page, so even when the
login crate emitted better sign-in diagnostics through TUI or app-server
flows, the one-shot CLI path still did not leave behind an easy artifact
to collect.
## Mental model
This implementation treats the browser page, the returned `io::Error`,
and the normal structured log as separate surfaces with different safety
requirements. The browser page and returned error preserve the detail
that operators need to diagnose failures. The structured log stays
narrower: it records reviewed lifecycle events, parsed safe fields, and
redacted transport errors without becoming a sink for secrets or
arbitrary backend bodies.
Direct `codex login` now adds a fourth support surface: a small
file-backed log at `codex-login.log` under the configured `log_dir`.
That artifact carries the same login-target events as the other
entrypoints without changing the existing stderr/browser UX.
## Non-goals
This does not add auth logging to normal runtime requests, and it does
not try to infer precise transport root causes from brittle string
matching. The scope remains the browser-login callback flow in the
`login` crate plus a direct-CLI wrapper that persists those events to
disk.
This also does not try to reuse the TUI logging stack wholesale. The TUI
path initializes feedback, OpenTelemetry, and other session-oriented
layers that are useful for an interactive app but unnecessary for a
one-shot login command.
## Tradeoffs
The implementation favors fidelity for caller-visible errors and
restraint for persistent logs. Parsed JSON token-endpoint errors are
logged safely by field. Non-JSON token-endpoint bodies remain available
to the returned error so CLI and browser surfaces still show backend
detail. Transport errors keep their real `reqwest` message, but attached
URLs are surgically redacted. Custom issuer URLs are sanitized before
logging.
On the CLI side, the code intentionally duplicates a narrow slice of the
TUI file-logging setup instead of sharing the full initializer. That
keeps `codex login` easy to reason about and avoids coupling it to
interactive-session layers that the command does not need.
## Architecture
The core auth behavior lives in `codex-rs/login/src/server.rs`. The
callback path now logs callback receipt, callback validation,
token-exchange start, token-exchange success, token-endpoint non-2xx
responses, and transport failures. App-server consumers still use this
same login-server path via `run_login_server(...)`, so the same
instrumentation benefits TUI, Electron, and VS Code extension flows.
The direct CLI path in `codex-rs/cli/src/login.rs` now installs a small
file-backed tracing layer for login commands only. That writes
`codex-login.log` under `log_dir` with login-specific targets such as
`codex_cli::login` and `codex_login::server`.
## Observability
The main signals come from the `login` crate target and are
intentionally scoped to sign-in. Structured logs include redacted issuer
URLs, redacted transport errors, HTTP status, and parsed token-endpoint
fields when available. The callback-layer log intentionally avoids
`%err` on token-endpoint failures so arbitrary backend bodies do not get
copied into the normal log file.
Direct `codex login` now leaves a durable artifact for both failure and
success cases. Example output from the new file-backed CLI path:
Failing callback:
```text
2026-03-06T22:08:54.143612Z INFO codex_cli::login: starting browser login flow
2026-03-06T22:09:03.431699Z INFO codex_login::server: received login callback path=/auth/callback has_code=false has_state=true has_error=true state_valid=true
2026-03-06T22:09:03.431745Z WARN codex_login::server: oauth callback returned error error_code="access_denied" has_error_description=true
```
Succeeded callback and token exchange:
```text
2026-03-06T22:09:14.065559Z INFO codex_cli::login: starting browser login flow
2026-03-06T22:09:36.431678Z INFO codex_login::server: received login callback path=/auth/callback has_code=true has_state=true has_error=false state_valid=true
2026-03-06T22:09:36.436977Z INFO codex_login::server: starting oauth token exchange issuer=https://auth.openai.com/ redirect_uri=http://localhost:1455/auth/callback
2026-03-06T22:09:36.685438Z INFO codex_login::server: oauth token exchange succeeded status=200 OK
```
## Tests
- `cargo test -p codex-login`
- `cargo clippy -p codex-login --tests -- -D warnings`
- `cargo test -p codex-cli`
- `just bazel-lock-update`
- `just bazel-lock-check`
- manual direct `codex login` smoke tests for both a failing callback
and a successful browser login
---------
Co-authored-by: Codex <noreply@openai.com>
2026-03-06 15:00:37 -08:00
|
|
|
tracing-appender = { workspace = true }
|
|
|
|
|
tracing-subscriber = { workspace = true }
|
2025-09-14 21:30:56 -07:00
|
|
|
|
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
|
|
|
[target.'cfg(target_os = "windows")'.dependencies]
|
|
|
|
|
codex_windows_sandbox = { package = "codex-windows-sandbox", path = "../windows-sandbox-rs" }
|
|
|
|
|
|
2025-09-14 21:30:56 -07:00
|
|
|
[dev-dependencies]
|
2025-09-22 18:47:01 +02:00
|
|
|
assert_cmd = { workspace = true }
|
2025-10-19 21:12:45 -07:00
|
|
|
assert_matches = { workspace = true }
|
2025-12-23 19:29:32 -08:00
|
|
|
codex-utils-cargo-bin = { workspace = true }
|
2025-09-22 18:47:01 +02:00
|
|
|
predicates = { workspace = true }
|
|
|
|
|
pretty_assertions = { workspace = true }
|
2026-02-27 17:45:55 -08:00
|
|
|
sqlx = { workspace = true }
|