https://github.com/openai/codex/pull/3395 updated `mcp-types/src/lib.rs` by hand, but that file is generated code that is produced by `mcp-types/generate_mcp_types.py`. Unfortunately, we do not have anything in CI to verify this right now, but I will address that in a subsequent PR. #3395 ended up introducing a change that added a required field when deserializing `InitializeResult`, breaking Codex when used as an MCP client, so the quick fix in #3436 was to make the new field `Optional` with `skip_serializing_if = "Option::is_none"`, but that did not address the problem that `mcp-types/generate_mcp_types.py` and `mcp-types/src/lib.rs` are out of sync. This PR gets things back to where they are in sync. It removes the custom `mcp_types::McpClientInfo` type that was added to `mcp-types/src/lib.rs` and forces us to use the generated `mcp_types::Implementation` type. Though this PR also updates `generate_mcp_types.py` to generate the additional `user_agent: Optional<String>` field on `Implementation` so that we can continue to specify it when Codex operates as an MCP server. However, this also requires us to specify `user_agent: None` when Codex operates as an MCP client. We may want to introduce our own `InitializeResult` type that is specific to when we run as a server to avoid this in the future, but my immediate goal is just to get things back in sync.
codex-core
This crate implements the business logic for Codex. It is designed to be used by the various Codex UIs written in Rust.
Dependencies
Note that codex-core makes some assumptions about certain helper utilities being available in the environment. Currently, this
macOS
Expects /usr/bin/sandbox-exec to be present.
Linux
Expects the binary containing codex-core to run the equivalent of codex debug landlock when arg0 is codex-linux-sandbox. See the codex-arg0 crate for details.
All Platforms
Expects the binary containing codex-core to simulate the virtual apply_patch CLI when arg1 is --codex-run-as-apply-patch. See the codex-arg0 crate for details.