core-agent-ide/codex-rs/rmcp-client/Cargo.toml

74 lines
2.1 KiB
TOML
Raw Normal View History

[package]
name = "codex-rmcp-client"
version.workspace = true
edition.workspace = true
license.workspace = true
[lints]
workspace = true
[dependencies]
anyhow = "1"
[MCP] Add support for MCP Oauth credentials (#4517) This PR adds oauth login support to streamable http servers when `experimental_use_rmcp_client` is enabled. This PR is large but represents the minimal amount of work required for this to work. To keep this PR smaller, login can only be done with `codex mcp login` and `codex mcp logout` but it doesn't appear in `/mcp` or `codex mcp list` yet. Fingers crossed that this is the last large MCP PR and that subsequent PRs can be smaller. Under the hood, credentials are stored using platform credential managers using the [keyring crate](https://crates.io/crates/keyring). When the keyring isn't available, it falls back to storing credentials in `CODEX_HOME/.credentials.json` which is consistent with how other coding agents handle authentication. I tested this on macOS, Windows, WSL (ubuntu), and Linux. I wasn't able to test the dbus store on linux but did verify that the fallback works. One quirk is that if you have credentials, during development, every build will have its own ad-hoc binary so the keyring won't recognize the reader as being the same as the write so it may ask for the user's password. I may add an override to disable this or allow users/enterprises to opt-out of the keyring storage if it causes issues. <img width="5064" height="686" alt="CleanShot 2025-09-30 at 19 31 40" src="https://github.com/user-attachments/assets/9573f9b4-07f1-4160-83b8-2920db287e2d" /> <img width="745" height="486" alt="image" src="https://github.com/user-attachments/assets/9562649b-ea5f-4f22-ace2-d0cb438b143e" />
2025-10-03 10:43:12 -07:00
axum = { workspace = true, default-features = false, features = [
"http1",
"tokio",
] }
codex-keyring-store = { workspace = true }
codex-protocol = { workspace = true }
codex-utils-pty = { workspace = true }
codex-utils-home-dir = { workspace = true }
futures = { workspace = true, default-features = false, features = ["std"] }
Fix FreeBSD/OpenBSD builds: target-specific keyring features and BSD hardening (#6680) ## Summary Builds on FreeBSD and OpenBSD were failing due to globally enabled Linux-specific keyring features and hardening code paths not gated by OS. This PR scopes keyring native backends to the appropriate targets, disables default features at the workspace root, and adds a BSD-specific hardening function. Linux/macOS/Windows behavior remains unchanged, while FreeBSD/OpenBSD now build and run with a supported backend. ## Key Changes - Keyring features: - Disable keyring default features at the workspace root to avoid pulling Linux backends on non-Linux. - Move native backend features into target-specific sections in the affected crates: - Linux: linux-native-async-persistent - macOS: apple-native - Windows: windows-native - FreeBSD/OpenBSD: sync-secret-service - Process hardening: - Add pre_main_hardening_bsd() for FreeBSD/OpenBSD, applying: - Set RLIMIT_CORE to 0 - Clear LD_* environment variables - Simplify process-hardening Cargo deps to unconditional libc (avoid conflicting OS fragments). - No changes to CODEX_SANDBOX_* behavior. ## Rationale - Previously, enabling keyring native backends globally pulled Linux-only features on BSD, causing build errors. - Hardening logic was tailored for Linux/macOS; BSD builds lacked a gated path with equivalent safeguards. - Target-scoped features and BSD hardening make the crates portable across these OSes without affecting existing behavior elsewhere. ## Impact by Platform - Linux: No functional change; backends now selected via target cfg. - macOS: No functional change; explicit apple-native mapping. - Windows: No functional change; explicit windows-native mapping. - FreeBSD/OpenBSD: Builds succeed using sync-secret-service; BSD hardening applied during startup. ## Testing - Verified compilation across affected crates with target-specific features. - Smoke-checked that Linux/macOS/Windows feature sets remain identical functionally after scoping. - On BSD, confirmed keyring resolves to sync-secret-service and hardening compiles. ## Risks / Compatibility - Minimal risk: only feature scoping and OS-gated additions. - No public API changes in the crates; runtime behavior on non-BSD platforms is preserved. - On BSD, the new hardening clears LD_*; this is consistent with security posture on other Unix platforms. ## Reviewer Notes - Pay attention to target-specific sections for keyring in the affected Cargo.toml files. - Confirm pre_main_hardening_bsd() mirrors the safe subset of Linux/macOS hardening without introducing Linux-only calls. - Confirm no references to CODEX_SANDBOX_ENV_VAR or CODEX_SANDBOX_NETWORK_DISABLED_ENV_VAR were added/modified. ## Checklist - Disable keyring default features at workspace root. - Target-specific keyring features mapped per OS (Linux/macOS/Windows/BSD). - Add BSD hardening (RLIMIT_CORE=0, clear LD_*). - Simplify process-hardening dependencies to unconditional libc. - No changes to sandbox env var code. - Formatting and linting: just fmt + just fix -p for changed crates. - Project tests pass for changed crates; broader suite unchanged. --------- Co-authored-by: celia-oai <celia@openai.com>
2025-11-16 23:07:34 -06:00
keyring = { workspace = true, features = ["crypto-rust"] }
oauth2 = "5"
reqwest = { version = "0.12", default-features = false, features = [
"json",
"stream",
"rustls-tls",
] }
[MCP] Add support for MCP Oauth credentials (#4517) This PR adds oauth login support to streamable http servers when `experimental_use_rmcp_client` is enabled. This PR is large but represents the minimal amount of work required for this to work. To keep this PR smaller, login can only be done with `codex mcp login` and `codex mcp logout` but it doesn't appear in `/mcp` or `codex mcp list` yet. Fingers crossed that this is the last large MCP PR and that subsequent PRs can be smaller. Under the hood, credentials are stored using platform credential managers using the [keyring crate](https://crates.io/crates/keyring). When the keyring isn't available, it falls back to storing credentials in `CODEX_HOME/.credentials.json` which is consistent with how other coding agents handle authentication. I tested this on macOS, Windows, WSL (ubuntu), and Linux. I wasn't able to test the dbus store on linux but did verify that the fallback works. One quirk is that if you have credentials, during development, every build will have its own ad-hoc binary so the keyring won't recognize the reader as being the same as the write so it may ask for the user's password. I may add an override to disable this or allow users/enterprises to opt-out of the keyring storage if it causes issues. <img width="5064" height="686" alt="CleanShot 2025-09-30 at 19 31 40" src="https://github.com/user-attachments/assets/9573f9b4-07f1-4160-83b8-2920db287e2d" /> <img width="745" height="486" alt="image" src="https://github.com/user-attachments/assets/9562649b-ea5f-4f22-ace2-d0cb438b143e" />
2025-10-03 10:43:12 -07:00
rmcp = { workspace = true, default-features = false, features = [
"auth",
"base64",
"client",
"macros",
"schemars",
"server",
"transport-child-process",
"transport-streamable-http-client-reqwest",
"transport-streamable-http-server",
] }
schemars = { workspace = true }
[MCP] Add support for MCP Oauth credentials (#4517) This PR adds oauth login support to streamable http servers when `experimental_use_rmcp_client` is enabled. This PR is large but represents the minimal amount of work required for this to work. To keep this PR smaller, login can only be done with `codex mcp login` and `codex mcp logout` but it doesn't appear in `/mcp` or `codex mcp list` yet. Fingers crossed that this is the last large MCP PR and that subsequent PRs can be smaller. Under the hood, credentials are stored using platform credential managers using the [keyring crate](https://crates.io/crates/keyring). When the keyring isn't available, it falls back to storing credentials in `CODEX_HOME/.credentials.json` which is consistent with how other coding agents handle authentication. I tested this on macOS, Windows, WSL (ubuntu), and Linux. I wasn't able to test the dbus store on linux but did verify that the fallback works. One quirk is that if you have credentials, during development, every build will have its own ad-hoc binary so the keyring won't recognize the reader as being the same as the write so it may ask for the user's password. I may add an override to disable this or allow users/enterprises to opt-out of the keyring storage if it causes issues. <img width="5064" height="686" alt="CleanShot 2025-09-30 at 19 31 40" src="https://github.com/user-attachments/assets/9573f9b4-07f1-4160-83b8-2920db287e2d" /> <img width="745" height="486" alt="image" src="https://github.com/user-attachments/assets/9562649b-ea5f-4f22-ace2-d0cb438b143e" />
2025-10-03 10:43:12 -07:00
serde = { workspace = true, features = ["derive"] }
serde_json = { workspace = true }
sha2 = { workspace = true }
tiny_http = { workspace = true }
tokio = { workspace = true, features = [
"io-util",
"macros",
"process",
"rt-multi-thread",
"sync",
"io-std",
"time",
] }
[MCP] Add support for MCP Oauth credentials (#4517) This PR adds oauth login support to streamable http servers when `experimental_use_rmcp_client` is enabled. This PR is large but represents the minimal amount of work required for this to work. To keep this PR smaller, login can only be done with `codex mcp login` and `codex mcp logout` but it doesn't appear in `/mcp` or `codex mcp list` yet. Fingers crossed that this is the last large MCP PR and that subsequent PRs can be smaller. Under the hood, credentials are stored using platform credential managers using the [keyring crate](https://crates.io/crates/keyring). When the keyring isn't available, it falls back to storing credentials in `CODEX_HOME/.credentials.json` which is consistent with how other coding agents handle authentication. I tested this on macOS, Windows, WSL (ubuntu), and Linux. I wasn't able to test the dbus store on linux but did verify that the fallback works. One quirk is that if you have credentials, during development, every build will have its own ad-hoc binary so the keyring won't recognize the reader as being the same as the write so it may ask for the user's password. I may add an override to disable this or allow users/enterprises to opt-out of the keyring storage if it causes issues. <img width="5064" height="686" alt="CleanShot 2025-09-30 at 19 31 40" src="https://github.com/user-attachments/assets/9573f9b4-07f1-4160-83b8-2920db287e2d" /> <img width="745" height="486" alt="image" src="https://github.com/user-attachments/assets/9562649b-ea5f-4f22-ace2-d0cb438b143e" />
2025-10-03 10:43:12 -07:00
tracing = { workspace = true, features = ["log"] }
urlencoding = { workspace = true }
webbrowser = { workspace = true }
fix: resolve Windows MCP server execution for script-based tools (#3828) ## What? Fixes MCP server initialization failures on Windows when using script-based tools like `npx`, `pnpm`, and `yarn` that rely on `.cmd`/`.bat` files rather than `.exe` binaries. Fixes #2945 ## Why? Windows users encounter "program not found" errors when configuring MCP servers with commands like `npx` in their `~/.codex/config.toml`. This happens because: - Tools like `npx` are batch scripts (`npx.cmd`) on Windows, not executable binaries - Rust's `std::process::Command` bypasses the shell and cannot execute these scripts directly - The Windows shell normally handles this by checking `PATHEXT` for executable extensions Without this fix, Windows users must specify full paths or add `.cmd` extensions manually, which breaks cross-platform compatibility. ## How? Added platform-specific program resolution using the `which` crate to find the correct executable path: - **Windows**: Resolves programs through PATH/PATHEXT to find `.cmd`/`.bat` scripts - **Unix**: Returns the program unchanged (no-op, as Unix handles scripts natively) ### Changes - Added `which = "6"` dependency to `mcp-client/Cargo.toml` - Implemented `program_resolver` module in `mcp_client.rs` with platform-specific resolution - Added comprehensive tests for both Windows and Unix behavior ### Testing Added platform-specific tests to verify: - Unix systems execute scripts without extensions - Windows fails without proper extensions - Windows succeeds with explicit extensions - Cross-platform resolution enables successful execution **Tested on:** - Windows 11 (NT 10.0.26100.0 x64) - PowerShell 5.1 & 7+, CMD, Git Bash - MCP servers: playwright, context7, supabase - WSL (verified no regression) **Local checks passed:** ```bash cargo test && cargo clippy --tests && cargo fmt -- --config imports_granularity=Item ``` ### Results **Before:** ``` 🖐 MCP client for `playwright` failed to start: program not found ``` **After:** ``` 🖐 MCP client for `playwright` failed to start: request timed out ``` Windows users can now use simple commands like `npx` in their config without specifying full paths or extensions. The timeout issue is a separate concern that will be addressed in a follow-up PR. --------- Co-authored-by: Eric Traut <etraut@openai.com>
2025-11-17 06:41:10 +09:00
which = { workspace = true }
[dev-dependencies]
feat: introduce codex-utils-cargo-bin as an alternative to assert_cmd::Command (#8496) This PR introduces a `codex-utils-cargo-bin` utility crate that wraps/replaces our use of `assert_cmd::Command` and `escargot::CargoBuild`. As you can infer from the introduction of `buck_project_root()` in this PR, I am attempting to make it possible to build Codex under [Buck2](https://buck2.build) as well as `cargo`. With Buck2, I hope to achieve faster incremental local builds (largely due to Buck2's [dice](https://buck2.build/docs/insights_and_knowledge/modern_dice/) build strategy, as well as benefits from its local build daemon) as well as faster CI builds if we invest in remote execution and caching. See https://buck2.build/docs/getting_started/what_is_buck2/#why-use-buck2-key-advantages for more details about the performance advantages of Buck2. Buck2 enforces stronger requirements in terms of build and test isolation. It discourages assumptions about absolute paths (which is key to enabling remote execution). Because the `CARGO_BIN_EXE_*` environment variables that Cargo provides are absolute paths (which `assert_cmd::Command` reads), this is a problem for Buck2, which is why we need this `codex-utils-cargo-bin` utility. My WIP-Buck2 setup sets the `CARGO_BIN_EXE_*` environment variables passed to a `rust_test()` build rule as relative paths. `codex-utils-cargo-bin` will resolve these values to absolute paths, when necessary. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/8496). * #8498 * __->__ #8496
2025-12-23 19:29:32 -08:00
codex-utils-cargo-bin = { workspace = true }
[MCP] Add support for MCP Oauth credentials (#4517) This PR adds oauth login support to streamable http servers when `experimental_use_rmcp_client` is enabled. This PR is large but represents the minimal amount of work required for this to work. To keep this PR smaller, login can only be done with `codex mcp login` and `codex mcp logout` but it doesn't appear in `/mcp` or `codex mcp list` yet. Fingers crossed that this is the last large MCP PR and that subsequent PRs can be smaller. Under the hood, credentials are stored using platform credential managers using the [keyring crate](https://crates.io/crates/keyring). When the keyring isn't available, it falls back to storing credentials in `CODEX_HOME/.credentials.json` which is consistent with how other coding agents handle authentication. I tested this on macOS, Windows, WSL (ubuntu), and Linux. I wasn't able to test the dbus store on linux but did verify that the fallback works. One quirk is that if you have credentials, during development, every build will have its own ad-hoc binary so the keyring won't recognize the reader as being the same as the write so it may ask for the user's password. I may add an override to disable this or allow users/enterprises to opt-out of the keyring storage if it causes issues. <img width="5064" height="686" alt="CleanShot 2025-09-30 at 19 31 40" src="https://github.com/user-attachments/assets/9573f9b4-07f1-4160-83b8-2920db287e2d" /> <img width="745" height="486" alt="image" src="https://github.com/user-attachments/assets/9562649b-ea5f-4f22-ace2-d0cb438b143e" />
2025-10-03 10:43:12 -07:00
pretty_assertions = { workspace = true }
serial_test = { workspace = true }
[MCP] Add support for MCP Oauth credentials (#4517) This PR adds oauth login support to streamable http servers when `experimental_use_rmcp_client` is enabled. This PR is large but represents the minimal amount of work required for this to work. To keep this PR smaller, login can only be done with `codex mcp login` and `codex mcp logout` but it doesn't appear in `/mcp` or `codex mcp list` yet. Fingers crossed that this is the last large MCP PR and that subsequent PRs can be smaller. Under the hood, credentials are stored using platform credential managers using the [keyring crate](https://crates.io/crates/keyring). When the keyring isn't available, it falls back to storing credentials in `CODEX_HOME/.credentials.json` which is consistent with how other coding agents handle authentication. I tested this on macOS, Windows, WSL (ubuntu), and Linux. I wasn't able to test the dbus store on linux but did verify that the fallback works. One quirk is that if you have credentials, during development, every build will have its own ad-hoc binary so the keyring won't recognize the reader as being the same as the write so it may ask for the user's password. I may add an override to disable this or allow users/enterprises to opt-out of the keyring storage if it causes issues. <img width="5064" height="686" alt="CleanShot 2025-09-30 at 19 31 40" src="https://github.com/user-attachments/assets/9573f9b4-07f1-4160-83b8-2920db287e2d" /> <img width="745" height="486" alt="image" src="https://github.com/user-attachments/assets/9562649b-ea5f-4f22-ace2-d0cb438b143e" />
2025-10-03 10:43:12 -07:00
tempfile = { workspace = true }
Fix FreeBSD/OpenBSD builds: target-specific keyring features and BSD hardening (#6680) ## Summary Builds on FreeBSD and OpenBSD were failing due to globally enabled Linux-specific keyring features and hardening code paths not gated by OS. This PR scopes keyring native backends to the appropriate targets, disables default features at the workspace root, and adds a BSD-specific hardening function. Linux/macOS/Windows behavior remains unchanged, while FreeBSD/OpenBSD now build and run with a supported backend. ## Key Changes - Keyring features: - Disable keyring default features at the workspace root to avoid pulling Linux backends on non-Linux. - Move native backend features into target-specific sections in the affected crates: - Linux: linux-native-async-persistent - macOS: apple-native - Windows: windows-native - FreeBSD/OpenBSD: sync-secret-service - Process hardening: - Add pre_main_hardening_bsd() for FreeBSD/OpenBSD, applying: - Set RLIMIT_CORE to 0 - Clear LD_* environment variables - Simplify process-hardening Cargo deps to unconditional libc (avoid conflicting OS fragments). - No changes to CODEX_SANDBOX_* behavior. ## Rationale - Previously, enabling keyring native backends globally pulled Linux-only features on BSD, causing build errors. - Hardening logic was tailored for Linux/macOS; BSD builds lacked a gated path with equivalent safeguards. - Target-scoped features and BSD hardening make the crates portable across these OSes without affecting existing behavior elsewhere. ## Impact by Platform - Linux: No functional change; backends now selected via target cfg. - macOS: No functional change; explicit apple-native mapping. - Windows: No functional change; explicit windows-native mapping. - FreeBSD/OpenBSD: Builds succeed using sync-secret-service; BSD hardening applied during startup. ## Testing - Verified compilation across affected crates with target-specific features. - Smoke-checked that Linux/macOS/Windows feature sets remain identical functionally after scoping. - On BSD, confirmed keyring resolves to sync-secret-service and hardening compiles. ## Risks / Compatibility - Minimal risk: only feature scoping and OS-gated additions. - No public API changes in the crates; runtime behavior on non-BSD platforms is preserved. - On BSD, the new hardening clears LD_*; this is consistent with security posture on other Unix platforms. ## Reviewer Notes - Pay attention to target-specific sections for keyring in the affected Cargo.toml files. - Confirm pre_main_hardening_bsd() mirrors the safe subset of Linux/macOS hardening without introducing Linux-only calls. - Confirm no references to CODEX_SANDBOX_ENV_VAR or CODEX_SANDBOX_NETWORK_DISABLED_ENV_VAR were added/modified. ## Checklist - Disable keyring default features at workspace root. - Target-specific keyring features mapped per OS (Linux/macOS/Windows/BSD). - Add BSD hardening (RLIMIT_CORE=0, clear LD_*). - Simplify process-hardening dependencies to unconditional libc. - No changes to sandbox env var code. - Formatting and linting: just fmt + just fix -p for changed crates. - Project tests pass for changed crates; broader suite unchanged. --------- Co-authored-by: celia-oai <celia@openai.com>
2025-11-16 23:07:34 -06:00
[target.'cfg(target_os = "linux")'.dependencies]
keyring = { workspace = true, features = ["linux-native-async-persistent"] }
[target.'cfg(target_os = "macos")'.dependencies]
keyring = { workspace = true, features = ["apple-native"] }
[target.'cfg(target_os = "windows")'.dependencies]
keyring = { workspace = true, features = ["windows-native"] }
[target.'cfg(any(target_os = "freebsd", target_os = "openbsd"))'.dependencies]
keyring = { workspace = true, features = ["sync-secret-service"] }