codex-rs/app-server-protocol/src/lib.rs

mod export;
mod jsonrpc_lite;
mod protocol;

pub use export::generate_json;
pub use export::generate_ts;
pub use export::generate_types;
pub use jsonrpc_lite::*;
pub use protocol::common::*;
pub use protocol::v1::*;
pub use protocol::v2::*;
Generate JSON schema for app-server protocol (#5063) Add annotations and an export script that let us generate app-server protocol types as typescript and JSONSchema. The script itself is a bit hacky because we need to manually label some of the types. Unfortunately it seems that enum variants don't get good names by default and end up with something like `EventMsg1`, `EventMsg2`, etc. I'm not an expert in this by any means, but since this is only run manually and we already need to enumerate the types required to describe the protocol, it didn't seem that much worse. An ideal solution here would be to have some kind of root that we could generate schemas for in one go, but I'm not sure if that's compatible with how we generate the protocol today. 2025-10-20 11:45:11 -07:00			`mod export;`
fix: remove mcp-types from app server protocol (#4537) We continue the separation between `codex app-server` and `codex mcp-server`. In particular, we introduce a new crate, `codex-app-server-protocol`, and migrate `codex-rs/protocol/src/mcp_protocol.rs` into it, renaming it `codex-rs/app-server-protocol/src/protocol.rs`. Because `ConversationId` was defined in `mcp_protocol.rs`, we move it into its own file, `codex-rs/protocol/src/conversation_id.rs`, and because it is referenced in a ton of places, we have to touch a lot of files as part of this PR. We also decide to get away from proper JSON-RPC 2.0 semantics, so we also introduce `codex-rs/app-server-protocol/src/jsonrpc_lite.rs`, which is basically the same `JSONRPCMessage` type defined in `mcp-types` except with all of the `"jsonrpc": "2.0"` removed. Getting rid of `"jsonrpc": "2.0"` makes our serialization logic considerably simpler, as we can lean heavier on serde to serialize directly into the wire format that we use now. 2025-09-30 19:16:26 -07:00			`mod jsonrpc_lite;`
			`mod protocol;`

Generate JSON schema for app-server protocol (#5063) Add annotations and an export script that let us generate app-server protocol types as typescript and JSONSchema. The script itself is a bit hacky because we need to manually label some of the types. Unfortunately it seems that enum variants don't get good names by default and end up with something like `EventMsg1`, `EventMsg2`, etc. I'm not an expert in this by any means, but since this is only run manually and we already need to enumerate the types required to describe the protocol, it didn't seem that much worse. An ideal solution here would be to have some kind of root that we could generate schemas for in one go, but I'm not sure if that's compatible with how we generate the protocol today. 2025-10-20 11:45:11 -07:00			`pub use export::generate_json;`
			`pub use export::generate_ts;`
			`pub use export::generate_types;`
fix: remove mcp-types from app server protocol (#4537) We continue the separation between `codex app-server` and `codex mcp-server`. In particular, we introduce a new crate, `codex-app-server-protocol`, and migrate `codex-rs/protocol/src/mcp_protocol.rs` into it, renaming it `codex-rs/app-server-protocol/src/protocol.rs`. Because `ConversationId` was defined in `mcp_protocol.rs`, we move it into its own file, `codex-rs/protocol/src/conversation_id.rs`, and because it is referenced in a ton of places, we have to touch a lot of files as part of this PR. We also decide to get away from proper JSON-RPC 2.0 semantics, so we also introduce `codex-rs/app-server-protocol/src/jsonrpc_lite.rs`, which is basically the same `JSONRPCMessage` type defined in `mcp-types` except with all of the `"jsonrpc": "2.0"` removed. Getting rid of `"jsonrpc": "2.0"` makes our serialization logic considerably simpler, as we can lean heavier on serde to serialize directly into the wire format that we use now. 2025-09-30 19:16:26 -07:00			`pub use jsonrpc_lite::*;`
[app-server] refactor: split API types into v1 and v2 (#6005) Makes it easier to figure out which types are defined in the old vs. new API schema. 2025-10-30 16:56:55 -07:00			`pub use protocol::common::*;`
			`pub use protocol::v1::*;`
			`pub use protocol::v2::*;`