Michael Bolin cc97982bbb core: use codex-mcp APIs directly (#16510) ...

## Why

`codex-mcp` already owns the shared MCP API surface, including `auth`,
`McpConfig`, `CODEX_APPS_MCP_SERVER_NAME`, and tool-name helpers in
[`codex-rs/codex-mcp/src/mcp/mod.rs`](https://github.com/openai/codex/blob/f61e85dbfb5373cde6827d232ac8ea447c237e81/codex-rs/codex-mcp/src/mcp/mod.rs#L1-L35).
Re-exporting that surface from `codex_core::mcp` gives downstream crates
two import paths for the same API and hides the real crate dependency.

This PR keeps `codex_core::mcp` focused on the local `McpManager`
wrapper in
[`codex-rs/core/src/mcp.rs`](https://github.com/openai/codex/blob/f61e85dbfb5373cde6827d232ac8ea447c237e81/codex-rs/core/src/mcp.rs#L13-L40)
and makes consumers import shared MCP APIs from `codex_mcp` directly.

## What

- Remove the `codex_mcp::mcp` re-export surface from `core/src/mcp.rs`.
- Update `codex-core` internals plus `codex-app-server`, `codex-cli`,
and `codex-tui` test code to import MCP APIs from `codex_mcp::mcp`
directly.
- Add explicit `codex-mcp` dependencies where those crates now use that
API surface, and refresh `Cargo.lock`.

## Verification

- `just bazel-lock-check`
- `cargo test -p codex-core -p codex-cli -p codex-tui`
  - `codex-cli` passed.
- `codex-core` still fails five unrelated config tests in
`core/src/config/config_tests.rs` (`approvals_reviewer_*` and
`smart_approvals_alias_*`).
- A broader `cargo test -p codex-core -p codex-app-server -p codex-cli
-p codex-tui` run previously hung in `codex-app-server` test
`in_process_start_uses_requested_session_source_for_thread_start`.

cc97982bbb · 2026-04-01 21:55:22 -07:00

History

..

src

core: use codex-mcp APIs directly (#16510)

2026-04-01 21:55:22 -07:00

tests

feat: simplify DB further (#13771)

2026-03-07 03:48:36 -08:00

BUILD.bazel

feat: add support for building with Bazel (#8875)

2026-01-09 11:09:43 -08:00

Cargo.toml

core: use codex-mcp APIs directly (#16510)

2026-04-01 21:55:22 -07:00