core/core-agent-ide
8
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
core-agent-ide/codex-rs/app-server-protocol/schema/json/ServerNotification.json

8201 lines
202 KiB
JSON
Raw Normal View History

feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
{
"$schema": "http://json-schema.org/draft-07/schema#",
"definitions": {
"AbsolutePathBuf": {
"description": "A path that is guaranteed to be absolute and normalized (though it is not guaranteed to be canonicalized or exist on the filesystem).\n\nIMPORTANT: When deserializing an `AbsolutePathBuf`, a base path must be set using [AbsolutePathBufGuard::new]. If no base path is set, the deserialization will fail unless the path being deserialized is already absolute.",
"type": "string"
},
"AccountLoginCompletedNotification": {
"properties": {
"error": {
"type": [
"string",
"null"
]
},
"loginId": {
"type": [
"string",
"null"
]
},
"success": {
"type": "boolean"
}
},
"required": [
"success"
],
"type": "object"
},
"AccountRateLimitsUpdatedNotification": {
"properties": {
"rateLimits": {
"$ref": "#/definitions/RateLimitSnapshot"
}
},
"required": [
"rateLimits"
],
"type": "object"
},
"AccountUpdatedNotification": {
"properties": {
"authMode": {
"anyOf": [
{
"$ref": "#/definitions/AuthMode"
},
{
"type": "null"
}
]
}
},
"type": "object"
},
"AgentMessageContent": {
"oneOf": [
{
"properties": {
"text": {
"type": "string"
},
"type": {
"enum": [
"Text"
],
"title": "TextAgentMessageContentType",
"type": "string"
}
},
"required": [
"text",
"type"
],
"title": "TextAgentMessageContent",
"type": "object"
}
]
},
"AgentMessageDeltaNotification": {
"properties": {
"delta": {
"type": "string"
},
"itemId": {
"type": "string"
},
"threadId": {
"type": "string"
},
"turnId": {
"type": "string"
}
},
"required": [
"delta",
"itemId",
"threadId",
"turnId"
],
"type": "object"
},
"AgentStatus": {
"description": "Agent lifecycle status, derived from emitted events.",
"oneOf": [
{
"description": "Agent is waiting for initialization.",
"enum": [
"pending_init"
],
"type": "string"
},
{
"description": "Agent is currently running.",
"enum": [
"running"
],
"type": "string"
},
{
"additionalProperties": false,
"description": "Agent is done. Contains the final assistant message.",
"properties": {
"completed": {
"type": [
"string",
"null"
]
}
},
"required": [
"completed"
],
"title": "CompletedAgentStatus",
"type": "object"
},
{
"additionalProperties": false,
"description": "Agent encountered an error.",
"properties": {
"errored": {
"type": "string"
}
},
"required": [
"errored"
],
"title": "ErroredAgentStatus",
"type": "object"
},
{
"description": "Agent has been shutdown.",
"enum": [
"shutdown"
],
"type": "string"
},
{
"description": "Agent is not found.",
"enum": [
"not_found"
],
"type": "string"
}
]
},
[apps] Improve app loading. (#10994) There are two concepts of apps that we load in the harness: - Directory apps, which is all the apps that the user can install. - Accessible apps, which is what the user actually installed and can be $ inserted and be used by the model. These are extracted from the tools that are loaded through the gateway MCP. Previously we wait for both sets of apps before returning the full apps list. Which causes many issues because accessible apps won't be available to the UI or the model if directory apps aren't loaded or failed to load. In this PR we are separating them so that accessible apps can be loaded separately and are instantly available to be shown in the UI and to be provided in model context. We also added an app-server event so that clients can subscribe to also get accessible apps without being blocked on the full app list. - [x] Separate accessible apps and directory apps loading. - [x] `app/list` request will also emit `app/list/updated` notifications that app-server clients can subscribe. Which allows clients to get accessible apps list to render in the $ menu without being blocked by directory apps. - [x] Cache both accessible and directory apps with 1 hour TTL to avoid reloading them when creating new threads. - [x] TUI improvements to redraw $ menu and /apps menu when app list is updated.
2026-02-08 15:24:56 -08:00
"AppInfo": {
"description": "EXPERIMENTAL - app metadata returned by app-list APIs.",
"properties": {
"description": {
"type": [
"string",
"null"
]
},
"distributionChannel": {
"type": [
"string",
"null"
]
},
"id": {
"type": "string"
},
"installUrl": {
"type": [
"string",
"null"
]
},
"isAccessible": {
"default": false,
"type": "boolean"
},
"logoUrl": {
"type": [
"string",
"null"
]
},
"logoUrlDark": {
"type": [
"string",
"null"
]
},
"name": {
"type": "string"
}
},
"required": [
"id",
"name"
],
"type": "object"
},
"AppListUpdatedNotification": {
"description": "EXPERIMENTAL - notification emitted when the app list changes.",
"properties": {
"data": {
"items": {
"$ref": "#/definitions/AppInfo"
},
"type": "array"
}
},
"required": [
"data"
],
"type": "object"
},
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
"AskForApproval": {
"description": "Determines the conditions under which the user is consulted to approve running the command proposed by Codex.",
"oneOf": [
{
"description": "Under this policy, only \"known safe\" commands—as determined by `is_safe_command()`—that **only read files** are auto‑approved. Everything else will ask the user to approve.",
"enum": [
"untrusted"
],
"type": "string"
},
{
"description": "*All* commands are auto‑approved, but they are expected to run inside a sandbox where network access is disabled and writes are confined to a specific set of paths. If the command fails, it will be escalated to the user to approve execution without a sandbox.",
"enum": [
"on-failure"
],
"type": "string"
},
{
"description": "The model decides when to ask the user for approval.",
"enum": [
"on-request"
],
"type": "string"
},
{
"description": "Never ask the user to approve commands. Failures are immediately returned to the model, and never escalated to the user for approval.",
"enum": [
"never"
],
"type": "string"
}
]
},
"AuthMode": {
"description": "Authentication mode for OpenAI-backed providers.",
"oneOf": [
{
"description": "OpenAI API key provided by the caller and stored by Codex.",
"enum": [
"apikey"
],
"type": "string"
},
{
"description": "ChatGPT OAuth managed by Codex (tokens persisted and refreshed by Codex).",
"enum": [
"chatgpt"
],
"type": "string"
},
{
"description": "[UNSTABLE] FOR OPENAI INTERNAL USE ONLY - DO NOT USE.\n\nChatGPT auth tokens are supplied by an external host app and are only stored in memory. Token refresh must be handled by the external host app.",
"enum": [
"chatgptAuthTokens"
],
"type": "string"
}
]
},
"AuthStatusChangeNotification": {
"description": "Deprecated notification. Use AccountUpdatedNotification instead.",
"properties": {
"authMethod": {
"anyOf": [
{
"$ref": "#/definitions/AuthMode"
},
{
"type": "null"
}
]
}
},
"type": "object"
},
"ByteRange": {
"properties": {
"end": {
"format": "uint",
"minimum": 0.0,
"type": "integer"
},
"start": {
"format": "uint",
"minimum": 0.0,
"type": "integer"
}
},
"required": [
"end",
"start"
],
"type": "object"
},
"ByteRange2": {
"properties": {
"end": {
"description": "End byte offset (exclusive) within the UTF-8 text buffer.",
"format": "uint",
"minimum": 0.0,
"type": "integer"
},
"start": {
"description": "Start byte offset (inclusive) within the UTF-8 text buffer.",
"format": "uint",
"minimum": 0.0,
"type": "integer"
}
},
"required": [
"end",
"start"
],
"type": "object"
},
"CallToolResult": {
"description": "The server's response to a tool call.",
"properties": {
feat: replace custom mcp-types crate with equivalents from rmcp (#10349) We started working with MCP in Codex before https://crates.io/crates/rmcp was mature, so we had our own crate for MCP types that was generated from the MCP schema: https://github.com/openai/codex/blob/8b95d3e082376f4cb23e92641705a22afb28a9da/codex-rs/mcp-types/README.md Now that `rmcp` is more mature, it makes more sense to use their MCP types in Rust, as they handle details (like the `_meta` field) that our custom version ignored. Though one advantage that our custom types had is that our generated types implemented `JsonSchema` and `ts_rs::TS`, whereas the types in `rmcp` do not. As such, part of the work of this PR is leveraging the adapters between `rmcp` types and the serializable types that are API for us (app server and MCP) introduced in #10356. Note this PR results in a number of changes to `codex-rs/app-server-protocol/schema`, which merit special attention during review. We must ensure that these changes are still backwards-compatible, which is possible because we have: ```diff - export type CallToolResult = { content: Array<ContentBlock>, isError?: boolean, structuredContent?: JsonValue, }; + export type CallToolResult = { content: Array<JsonValue>, structuredContent?: JsonValue, isError?: boolean, _meta?: JsonValue, }; ``` so `ContentBlock` has been replaced with the more general `JsonValue`. Note that `ContentBlock` was defined as: ```typescript export type ContentBlock = TextContent | ImageContent | AudioContent | ResourceLink | EmbeddedResource; ``` so the deletion of those individual variants should not be a cause of great concern. Similarly, we have the following change in `codex-rs/app-server-protocol/schema/typescript/Tool.ts`: ``` - export type Tool = { annotations?: ToolAnnotations, description?: string, inputSchema: ToolInputSchema, name: string, outputSchema?: ToolOutputSchema, title?: string, }; + export type Tool = { name: string, title?: string, description?: string, inputSchema: JsonValue, outputSchema?: JsonValue, annotations?: JsonValue, icons?: Array<JsonValue>, _meta?: JsonValue, }; ``` so: - `annotations?: ToolAnnotations` ➡️ `JsonValue` - `inputSchema: ToolInputSchema` ➡️ `JsonValue` - `outputSchema?: ToolOutputSchema` ➡️ `JsonValue` and two new fields: `icons?: Array<JsonValue>, _meta?: JsonValue` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10349). * #10357 * __->__ #10349 * #10356
2026-02-02 17:41:55 -08:00
"_meta": true,
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
"content": {
feat: replace custom mcp-types crate with equivalents from rmcp (#10349) We started working with MCP in Codex before https://crates.io/crates/rmcp was mature, so we had our own crate for MCP types that was generated from the MCP schema: https://github.com/openai/codex/blob/8b95d3e082376f4cb23e92641705a22afb28a9da/codex-rs/mcp-types/README.md Now that `rmcp` is more mature, it makes more sense to use their MCP types in Rust, as they handle details (like the `_meta` field) that our custom version ignored. Though one advantage that our custom types had is that our generated types implemented `JsonSchema` and `ts_rs::TS`, whereas the types in `rmcp` do not. As such, part of the work of this PR is leveraging the adapters between `rmcp` types and the serializable types that are API for us (app server and MCP) introduced in #10356. Note this PR results in a number of changes to `codex-rs/app-server-protocol/schema`, which merit special attention during review. We must ensure that these changes are still backwards-compatible, which is possible because we have: ```diff - export type CallToolResult = { content: Array<ContentBlock>, isError?: boolean, structuredContent?: JsonValue, }; + export type CallToolResult = { content: Array<JsonValue>, structuredContent?: JsonValue, isError?: boolean, _meta?: JsonValue, }; ``` so `ContentBlock` has been replaced with the more general `JsonValue`. Note that `ContentBlock` was defined as: ```typescript export type ContentBlock = TextContent | ImageContent | AudioContent | ResourceLink | EmbeddedResource; ``` so the deletion of those individual variants should not be a cause of great concern. Similarly, we have the following change in `codex-rs/app-server-protocol/schema/typescript/Tool.ts`: ``` - export type Tool = { annotations?: ToolAnnotations, description?: string, inputSchema: ToolInputSchema, name: string, outputSchema?: ToolOutputSchema, title?: string, }; + export type Tool = { name: string, title?: string, description?: string, inputSchema: JsonValue, outputSchema?: JsonValue, annotations?: JsonValue, icons?: Array<JsonValue>, _meta?: JsonValue, }; ``` so: - `annotations?: ToolAnnotations` ➡️ `JsonValue` - `inputSchema: ToolInputSchema` ➡️ `JsonValue` - `outputSchema?: ToolOutputSchema` ➡️ `JsonValue` and two new fields: `icons?: Array<JsonValue>, _meta?: JsonValue` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10349). * #10357 * __->__ #10349 * #10356
2026-02-02 17:41:55 -08:00
"items": true,
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
"type": "array"
},
"isError": {
"type": [
"boolean",
"null"
]
},
"structuredContent": true
},
"required": [
"content"
],
"type": "object"
},
"CodexErrorInfo": {
"description": "This translation layer make sure that we expose codex error code in camel case.\n\nWhen an upstream HTTP status is available (for example, from the Responses API or a provider), it is forwarded in `httpStatusCode` on the relevant `codexErrorInfo` variant.",
"oneOf": [
{
"enum": [
"contextWindowExceeded",
"usageLimitExceeded",
"internalServerError",
"unauthorized",
"badRequest",
"threadRollbackFailed",
"sandboxError",
"other"
],
"type": "string"
},
{
"additionalProperties": false,
"properties": {
"modelCap": {
"properties": {
"model": {
"type": "string"
},
"reset_after_seconds": {
"format": "uint64",
"minimum": 0.0,
"type": [
"integer",
"null"
]
}
},
"required": [
"model"
],
"type": "object"
}
},
"required": [
"modelCap"
],
"title": "ModelCapCodexErrorInfo",
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"httpConnectionFailed": {
"properties": {
"httpStatusCode": {
"format": "uint16",
"minimum": 0.0,
"type": [
"integer",
"null"
]
}
},
"type": "object"
}
},
"required": [
"httpConnectionFailed"
],
"title": "HttpConnectionFailedCodexErrorInfo",
"type": "object"
},
{
"additionalProperties": false,
"description": "Failed to connect to the response SSE stream.",
"properties": {
"responseStreamConnectionFailed": {
"properties": {
"httpStatusCode": {
"format": "uint16",
"minimum": 0.0,
"type": [
"integer",
"null"
]
}
},
"type": "object"
}
},
"required": [
"responseStreamConnectionFailed"
],
"title": "ResponseStreamConnectionFailedCodexErrorInfo",
"type": "object"
},
{
"additionalProperties": false,
"description": "The response SSE stream disconnected in the middle of a turn before completion.",
"properties": {
"responseStreamDisconnected": {
"properties": {
"httpStatusCode": {
"format": "uint16",
"minimum": 0.0,
"type": [
"integer",
"null"
]
}
},
"type": "object"
}
},
"required": [
"responseStreamDisconnected"
],
"title": "ResponseStreamDisconnectedCodexErrorInfo",
"type": "object"
},
{
"additionalProperties": false,
"description": "Reached the retry limit for responses.",
"properties": {
"responseTooManyFailedAttempts": {
"properties": {
"httpStatusCode": {
"format": "uint16",
"minimum": 0.0,
"type": [
"integer",
"null"
]
}
},
"type": "object"
}
},
"required": [
"responseTooManyFailedAttempts"
],
"title": "ResponseTooManyFailedAttemptsCodexErrorInfo",
"type": "object"
}
]
},
"CodexErrorInfo2": {
"description": "Codex errors that we expose to clients.",
"oneOf": [
{
"enum": [
"context_window_exceeded",
"usage_limit_exceeded",
"internal_server_error",
"unauthorized",
"bad_request",
"sandbox_error",
"thread_rollback_failed",
"other"
],
"type": "string"
},
{
"additionalProperties": false,
"properties": {
"model_cap": {
"properties": {
"model": {
"type": "string"
},
"reset_after_seconds": {
"format": "uint64",
"minimum": 0.0,
"type": [
"integer",
"null"
]
}
},
"required": [
"model"
],
"type": "object"
}
},
"required": [
"model_cap"
],
"title": "ModelCapCodexErrorInfo2",
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"http_connection_failed": {
"properties": {
"http_status_code": {
"format": "uint16",
"minimum": 0.0,
"type": [
"integer",
"null"
]
}
},
"type": "object"
}
},
"required": [
"http_connection_failed"
],
"title": "HttpConnectionFailedCodexErrorInfo2",
"type": "object"
},
{
"additionalProperties": false,
"description": "Failed to connect to the response SSE stream.",
"properties": {
"response_stream_connection_failed": {
"properties": {
"http_status_code": {
"format": "uint16",
"minimum": 0.0,
"type": [
"integer",
"null"
]
}
},
"type": "object"
}
},
"required": [
"response_stream_connection_failed"
],
"title": "ResponseStreamConnectionFailedCodexErrorInfo2",
"type": "object"
},
{
"additionalProperties": false,
"description": "The response SSE stream disconnected in the middle of a turnbefore completion.",
"properties": {
"response_stream_disconnected": {
"properties": {
"http_status_code": {
"format": "uint16",
"minimum": 0.0,
"type": [
"integer",
"null"
]
}
},
"type": "object"
}
},
"required": [
"response_stream_disconnected"
],
"title": "ResponseStreamDisconnectedCodexErrorInfo2",
"type": "object"
},
{
"additionalProperties": false,
"description": "Reached the retry limit for responses.",
"properties": {
"response_too_many_failed_attempts": {
"properties": {
"http_status_code": {
"format": "uint16",
"minimum": 0.0,
"type": [
"integer",
"null"
]
}
},
"type": "object"
}
},
"required": [
"response_too_many_failed_attempts"
],
"title": "ResponseTooManyFailedAttemptsCodexErrorInfo2",
"type": "object"
}
]
},
"CollabAgentState": {
"properties": {
"message": {
"type": [
"string",
"null"
]
},
"status": {
"$ref": "#/definitions/CollabAgentStatus"
}
},
"required": [
"status"
],
"type": "object"
},
"CollabAgentStatus": {
"enum": [
"pendingInit",
"running",
"completed",
"errored",
"shutdown",
"notFound"
],
"type": "string"
},
"CollabAgentTool": {
"enum": [
"spawnAgent",
"sendInput",
Add resume_agent collab tool (#10903) Summary - add the new resume_agent collab tool path through core, protocol, and the app server API, including the resume events - update the schema/TypeScript definitions plus docs so resume_agent appears in generated artifacts and README - note that resumed agents rehydrate rollout history without overwriting their base instructions Testing - Not run (not requested)
2026-02-07 17:31:45 +01:00
"resumeAgent",
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
"wait",
"closeAgent"
],
"type": "string"
},
"CollabAgentToolCallStatus": {
"enum": [
"inProgress",
"completed",
"failed"
],
"type": "string"
},
"CommandAction": {
"oneOf": [
{
"properties": {
"command": {
"type": "string"
},
"name": {
"type": "string"
},
"path": {
"type": "string"
},
"type": {
"enum": [
"read"
],
"title": "ReadCommandActionType",
"type": "string"
}
},
"required": [
"command",
"name",
"path",
"type"
],
"title": "ReadCommandAction",
"type": "object"
},
{
"properties": {
"command": {
"type": "string"
},
"path": {
"type": [
"string",
"null"
]
},
"type": {
"enum": [
"listFiles"
],
"title": "ListFilesCommandActionType",
"type": "string"
}
},
"required": [
"command",
"type"
],
"title": "ListFilesCommandAction",
"type": "object"
},
{
"properties": {
"command": {
"type": "string"
},
"path": {
"type": [
"string",
"null"
]
},
"query": {
"type": [
"string",
"null"
]
},
"type": {
"enum": [
"search"
],
"title": "SearchCommandActionType",
"type": "string"
}
},
"required": [
"command",
"type"
],
"title": "SearchCommandAction",
"type": "object"
},
{
"properties": {
"command": {
"type": "string"
},
"type": {
"enum": [
"unknown"
],
"title": "UnknownCommandActionType",
"type": "string"
}
},
"required": [
"command",
"type"
],
"title": "UnknownCommandAction",
"type": "object"
}
]
},
"CommandExecutionOutputDeltaNotification": {
"properties": {
"delta": {
"type": "string"
},
"itemId": {
"type": "string"
},
"threadId": {
"type": "string"
},
"turnId": {
"type": "string"
}
},
"required": [
"delta",
"itemId",
"threadId",
"turnId"
],
"type": "object"
},
"CommandExecutionStatus": {
"enum": [
"inProgress",
"completed",
"failed",
"declined"
],
"type": "string"
},
"ConfigWarningNotification": {
"properties": {
"details": {
"description": "Optional extra guidance or error details.",
"type": [
"string",
"null"
]
},
"path": {
"description": "Optional path to the config file that triggered the warning.",
"type": [
"string",
"null"
]
},
"range": {
"anyOf": [
{
"$ref": "#/definitions/TextRange"
},
{
"type": "null"
}
],
"description": "Optional range for the error location inside the config file."
},
"summary": {
"description": "Concise summary of the warning.",
"type": "string"
}
},
"required": [
"summary"
],
"type": "object"
},
"ContentItem": {
"oneOf": [
{
"properties": {
"text": {
"type": "string"
},
"type": {
"enum": [
"input_text"
],
"title": "InputTextContentItemType",
"type": "string"
}
},
"required": [
"text",
"type"
],
"title": "InputTextContentItem",
"type": "object"
},
{
"properties": {
"image_url": {
"type": "string"
},
"type": {
"enum": [
"input_image"
],
"title": "InputImageContentItemType",
"type": "string"
}
},
"required": [
"image_url",
"type"
],
"title": "InputImageContentItem",
"type": "object"
},
{
"properties": {
"text": {
"type": "string"
},
"type": {
"enum": [
"output_text"
],
"title": "OutputTextContentItemType",
"type": "string"
}
},
"required": [
"text",
"type"
],
"title": "OutputTextContentItem",
"type": "object"
}
]
},
"ContextCompactedNotification": {
"description": "Deprecated: Use `ContextCompaction` item type instead.",
"properties": {
"threadId": {
"type": "string"
},
"turnId": {
"type": "string"
}
},
"required": [
"threadId",
"turnId"
],
"type": "object"
},
"CreditsSnapshot": {
"properties": {
"balance": {
"type": [
"string",
"null"
]
},
"hasCredits": {
"type": "boolean"
},
"unlimited": {
"type": "boolean"
}
},
"required": [
"hasCredits",
"unlimited"
],
"type": "object"
},
"CreditsSnapshot2": {
"properties": {
"balance": {
"type": [
"string",
"null"
]
},
"has_credits": {
"type": "boolean"
},
"unlimited": {
"type": "boolean"
}
},
"required": [
"has_credits",
"unlimited"
],
"type": "object"
},
"CustomPrompt": {
"properties": {
"argument_hint": {
"type": [
"string",
"null"
]
},
"content": {
"type": "string"
},
"description": {
"type": [
"string",
"null"
]
},
"name": {
"type": "string"
},
"path": {
"type": "string"
}
},
"required": [
"content",
"name",
"path"
],
"type": "object"
},
"DeprecationNoticeNotification": {
"properties": {
"details": {
"description": "Optional extra guidance, such as migration steps or rationale.",
"type": [
"string",
"null"
]
},
"summary": {
"description": "Concise summary of what is deprecated.",
"type": "string"
}
},
"required": [
"summary"
],
"type": "object"
},
"Duration": {
"properties": {
"nanos": {
"format": "uint32",
"minimum": 0.0,
"type": "integer"
},
"secs": {
"format": "uint64",
"minimum": 0.0,
"type": "integer"
}
},
"required": [
"nanos",
"secs"
],
"type": "object"
},
"ErrorNotification": {
"properties": {
"error": {
"$ref": "#/definitions/TurnError"
},
"threadId": {
"type": "string"
},
"turnId": {
"type": "string"
},
"willRetry": {
"type": "boolean"
}
},
"required": [
"error",
"threadId",
"turnId",
"willRetry"
],
"type": "object"
},
"EventMsg": {
"description": "Response event from the agent NOTE: Make sure none of these values have optional types, as it will mess up the extension code-gen.",
"oneOf": [
{
"description": "Error while executing a submission",
"properties": {
"codex_error_info": {
"anyOf": [
{
"$ref": "#/definitions/CodexErrorInfo2"
},
{
"type": "null"
}
],
"default": null
},
"message": {
"type": "string"
},
"type": {
"enum": [
"error"
],
"title": "ErrorEventMsgType",
"type": "string"
}
},
"required": [
"message",
"type"
],
"title": "ErrorEventMsg",
"type": "object"
},
{
"description": "Warning issued while processing a submission. Unlike `Error`, this indicates the turn continued but the user should still be notified.",
"properties": {
"message": {
"type": "string"
},
"type": {
"enum": [
"warning"
],
"title": "WarningEventMsgType",
"type": "string"
}
},
"required": [
"message",
"type"
],
"title": "WarningEventMsg",
"type": "object"
},
{
"description": "Conversation history was compacted (either automatically or manually).",
"properties": {
"type": {
"enum": [
"context_compacted"
],
"title": "ContextCompactedEventMsgType",
"type": "string"
}
},
"required": [
"type"
],
"title": "ContextCompactedEventMsg",
"type": "object"
},
{
"description": "Conversation history was rolled back by dropping the last N user turns.",
"properties": {
"num_turns": {
"description": "Number of user turns that were removed from context.",
"format": "uint32",
"minimum": 0.0,
"type": "integer"
},
"type": {
"enum": [
"thread_rolled_back"
],
"title": "ThreadRolledBackEventMsgType",
"type": "string"
}
},
"required": [
"num_turns",
"type"
],
"title": "ThreadRolledBackEventMsg",
"type": "object"
},
{
"description": "Agent has started a turn. v1 wire format uses `task_started`; accept `turn_started` for v2 interop.",
"properties": {
"collaboration_mode_kind": {
"allOf": [
{
"$ref": "#/definitions/ModeKind"
}
],
Cleanup collaboration mode variants (#10404) ## Summary This PR simplifies collaboration modes to the visible set `default | plan`, while preserving backward compatibility for older partners that may still send legacy mode names. Specifically: - Renames the old Code behavior to **Default**. - Keeps **Plan** as-is. - Removes **Custom** mode behavior (fallbacks now resolve to Default). - Keeps `PairProgramming` and `Execute` internally for compatibility plumbing, while removing them from schema/API and UI visibility. - Adds legacy input aliasing so older clients can still send old mode names. ## What Changed 1. Mode enum and compatibility - `ModeKind` now uses `Plan` + `Default` as active/public modes. - `ModeKind::Default` deserialization accepts legacy values: - `code` - `pair_programming` - `execute` - `custom` - `PairProgramming` and `Execute` variants remain in code but are hidden from protocol/schema generation. - `Custom` variant is removed; previous custom fallbacks now map to `Default`. 2. Collaboration presets and templates - Built-in presets now return only: - `Plan` - `Default` - Template rename: - `core/templates/collaboration_mode/code.md` -> `default.md` - `execute.md` and `pair_programming.md` remain on disk but are not surfaced in visible preset lists. 3. TUI updates - Updated user-facing naming and prompts from “Code” to “Default”. - Updated mode-cycle and indicator behavior to reflect only visible `Plan` and `Default`. - Updated corresponding tests and snapshots. 4. request_user_input behavior - `request_user_input` remains allowed only in `Plan` mode. - Rejection messaging now consistently treats non-plan modes as `Default`. 5. Schemas - Regenerated config and app-server schemas. - Public schema types now advertise mode values as: - `plan` - `default` ## Backward Compatibility Notes - Incoming legacy mode names (`code`, `pair_programming`, `execute`, `custom`) are accepted and coerced to `default`. - Outgoing/public schema surfaces intentionally expose only `plan | default`. - This allows tolerant ingestion of older partner payloads while standardizing new integrations on the reduced mode set. ## Codex author `codex fork 019c1fae-693b-7840-b16e-9ad38ea0bd00`
2026-02-03 09:23:53 -08:00
"default": "default"
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
},
"model_context_window": {
"format": "int64",
"type": [
"integer",
"null"
]
},
"type": {
"enum": [
"task_started"
],
"title": "TaskStartedEventMsgType",
"type": "string"
}
},
"required": [
"type"
],
"title": "TaskStartedEventMsg",
"type": "object"
},
{
"description": "Agent has completed all actions. v1 wire format uses `task_complete`; accept `turn_complete` for v2 interop.",
"properties": {
"last_agent_message": {
"type": [
"string",
"null"
]
},
"type": {
"enum": [
"task_complete"
],
"title": "TaskCompleteEventMsgType",
"type": "string"
}
},
"required": [
"type"
],
"title": "TaskCompleteEventMsg",
"type": "object"
},
{
"description": "Usage update for the current session, including totals and last turn. Optional means unknown — UIs should not display when `None`.",
"properties": {
"info": {
"anyOf": [
{
"$ref": "#/definitions/TokenUsageInfo"
},
{
"type": "null"
}
]
},
"rate_limits": {
"anyOf": [
{
"$ref": "#/definitions/RateLimitSnapshot2"
},
{
"type": "null"
}
]
},
"type": {
"enum": [
"token_count"
],
"title": "TokenCountEventMsgType",
"type": "string"
}
},
"required": [
"type"
],
"title": "TokenCountEventMsg",
"type": "object"
},
{
"description": "Agent text output message",
"properties": {
"message": {
"type": "string"
},
"type": {
"enum": [
"agent_message"
],
"title": "AgentMessageEventMsgType",
"type": "string"
}
},
"required": [
"message",
"type"
],
"title": "AgentMessageEventMsg",
"type": "object"
},
{
"description": "User/system input message (what was sent to the model)",
"properties": {
"images": {
"description": "Image URLs sourced from `UserInput::Image`. These are safe to replay in legacy UI history events and correspond to images sent to the model.",
"items": {
"type": "string"
},
"type": [
"array",
"null"
]
},
"local_images": {
"default": [],
"description": "Local file paths sourced from `UserInput::LocalImage`. These are kept so the UI can reattach images when editing history, and should not be sent to the model or treated as API-ready URLs.",
"items": {
"type": "string"
},
"type": "array"
},
"message": {
"type": "string"
},
"text_elements": {
"default": [],
"description": "UI-defined spans within `message` used to render or persist special elements.",
"items": {
"$ref": "#/definitions/TextElement2"
},
"type": "array"
},
"type": {
"enum": [
"user_message"
],
"title": "UserMessageEventMsgType",
"type": "string"
}
},
"required": [
"message",
"type"
],
"title": "UserMessageEventMsg",
"type": "object"
},
{
"description": "Agent text output delta message",
"properties": {
"delta": {
"type": "string"
},
"type": {
"enum": [
"agent_message_delta"
],
"title": "AgentMessageDeltaEventMsgType",
"type": "string"
}
},
"required": [
"delta",
"type"
],
"title": "AgentMessageDeltaEventMsg",
"type": "object"
},
{
"description": "Reasoning event from agent.",
"properties": {
"text": {
"type": "string"
},
"type": {
"enum": [
"agent_reasoning"
],
"title": "AgentReasoningEventMsgType",
"type": "string"
}
},
"required": [
"text",
"type"
],
"title": "AgentReasoningEventMsg",
"type": "object"
},
{
"description": "Agent reasoning delta event from agent.",
"properties": {
"delta": {
"type": "string"
},
"type": {
"enum": [
"agent_reasoning_delta"
],
"title": "AgentReasoningDeltaEventMsgType",
"type": "string"
}
},
"required": [
"delta",
"type"
],
"title": "AgentReasoningDeltaEventMsg",
"type": "object"
},
{
"description": "Raw chain-of-thought from agent.",
"properties": {
"text": {
"type": "string"
},
"type": {
"enum": [
"agent_reasoning_raw_content"
],
"title": "AgentReasoningRawContentEventMsgType",
"type": "string"
}
},
"required": [
"text",
"type"
],
"title": "AgentReasoningRawContentEventMsg",
"type": "object"
},
{
"description": "Agent reasoning content delta event from agent.",
"properties": {
"delta": {
"type": "string"
},
"type": {
"enum": [
"agent_reasoning_raw_content_delta"
],
"title": "AgentReasoningRawContentDeltaEventMsgType",
"type": "string"
}
},
"required": [
"delta",
"type"
],
"title": "AgentReasoningRawContentDeltaEventMsg",
"type": "object"
},
{
"description": "Signaled when the model begins a new reasoning summary section (e.g., a new titled block).",
"properties": {
"item_id": {
"default": "",
"type": "string"
},
"summary_index": {
"default": 0,
"format": "int64",
"type": "integer"
},
"type": {
"enum": [
"agent_reasoning_section_break"
],
"title": "AgentReasoningSectionBreakEventMsgType",
"type": "string"
}
},
"required": [
"type"
],
"title": "AgentReasoningSectionBreakEventMsg",
"type": "object"
},
{
"description": "Ack the client's configure message.",
"properties": {
"approval_policy": {
"allOf": [
{
"$ref": "#/definitions/AskForApproval"
}
],
"description": "When to escalate for approval for execution"
},
"cwd": {
"description": "Working directory that should be treated as the *root* of the session.",
"type": "string"
},
"forked_from_id": {
"anyOf": [
{
"$ref": "#/definitions/ThreadId"
},
{
"type": "null"
}
]
},
"history_entry_count": {
"description": "Current number of entries in the history log.",
"format": "uint",
"minimum": 0.0,
"type": "integer"
},
"history_log_id": {
"description": "Identifier of the history log file (inode on Unix, 0 otherwise).",
"format": "uint64",
"minimum": 0.0,
"type": "integer"
},
"initial_messages": {
"description": "Optional initial messages (as events) for resumed sessions. When present, UIs can use these to seed the history.",
"items": {
"$ref": "#/definitions/EventMsg"
},
"type": [
"array",
"null"
]
},
"model": {
"description": "Tell the client what model is being queried.",
"type": "string"
},
"model_provider_id": {
"type": "string"
},
"reasoning_effort": {
"anyOf": [
{
"$ref": "#/definitions/ReasoningEffort"
},
{
"type": "null"
}
],
"description": "The effort the model is putting into reasoning about the user's request."
},
"rollout_path": {
"description": "Path in which the rollout is stored. Can be `None` for ephemeral threads",
"type": [
"string",
"null"
]
},
"sandbox_policy": {
"allOf": [
{
"$ref": "#/definitions/SandboxPolicy"
}
],
"description": "How to sandbox commands executed in the system"
},
"session_id": {
"$ref": "#/definitions/ThreadId"
},
"thread_name": {
"description": "Optional user-facing thread name (may be unset).",
"type": [
"string",
"null"
]
},
"type": {
"enum": [
"session_configured"
],
"title": "SessionConfiguredEventMsgType",
"type": "string"
}
},
"required": [
"approval_policy",
"cwd",
"history_entry_count",
"history_log_id",
"model",
"model_provider_id",
"sandbox_policy",
"session_id",
"type"
],
"title": "SessionConfiguredEventMsg",
"type": "object"
},
{
"description": "Updated session metadata (e.g., thread name changes).",
"properties": {
"thread_id": {
"$ref": "#/definitions/ThreadId"
},
"thread_name": {
"type": [
"string",
"null"
]
},
"type": {
"enum": [
"thread_name_updated"
],
"title": "ThreadNameUpdatedEventMsgType",
"type": "string"
}
},
"required": [
"thread_id",
"type"
],
"title": "ThreadNameUpdatedEventMsg",
"type": "object"
},
{
"description": "Incremental MCP startup progress updates.",
"properties": {
"server": {
"description": "Server name being started.",
"type": "string"
},
"status": {
"allOf": [
{
"$ref": "#/definitions/McpStartupStatus"
}
],
"description": "Current startup status."
},
"type": {
"enum": [
"mcp_startup_update"
],
"title": "McpStartupUpdateEventMsgType",
"type": "string"
}
},
"required": [
"server",
"status",
"type"
],
"title": "McpStartupUpdateEventMsg",
"type": "object"
},
{
"description": "Aggregate MCP startup completion summary.",
"properties": {
"cancelled": {
"items": {
"type": "string"
},
"type": "array"
},
"failed": {
"items": {
"$ref": "#/definitions/McpStartupFailure"
},
"type": "array"
},
"ready": {
"items": {
"type": "string"
},
"type": "array"
},
"type": {
"enum": [
"mcp_startup_complete"
],
"title": "McpStartupCompleteEventMsgType",
"type": "string"
}
},
"required": [
"cancelled",
"failed",
"ready",
"type"
],
"title": "McpStartupCompleteEventMsg",
"type": "object"
},
{
"properties": {
"call_id": {
"description": "Identifier so this can be paired with the McpToolCallEnd event.",
"type": "string"
},
"invocation": {
"$ref": "#/definitions/McpInvocation"
},
"type": {
"enum": [
"mcp_tool_call_begin"
],
"title": "McpToolCallBeginEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"invocation",
"type"
],
"title": "McpToolCallBeginEventMsg",
"type": "object"
},
{
"properties": {
"call_id": {
"description": "Identifier for the corresponding McpToolCallBegin that finished.",
"type": "string"
},
"duration": {
"$ref": "#/definitions/Duration"
},
"invocation": {
"$ref": "#/definitions/McpInvocation"
},
"result": {
"allOf": [
{
"$ref": "#/definitions/Result_of_CallToolResult_or_String"
}
],
"description": "Result of the tool call. Note this could be an error."
},
"type": {
"enum": [
"mcp_tool_call_end"
],
"title": "McpToolCallEndEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"duration",
"invocation",
"result",
"type"
],
"title": "McpToolCallEndEventMsg",
"type": "object"
},
{
"properties": {
"call_id": {
"type": "string"
},
"type": {
"enum": [
"web_search_begin"
],
"title": "WebSearchBeginEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"type"
],
"title": "WebSearchBeginEventMsg",
"type": "object"
},
{
"properties": {
"action": {
"$ref": "#/definitions/WebSearchAction2"
},
"call_id": {
"type": "string"
},
"query": {
"type": "string"
},
"type": {
"enum": [
"web_search_end"
],
"title": "WebSearchEndEventMsgType",
"type": "string"
}
},
"required": [
"action",
"call_id",
"query",
"type"
],
"title": "WebSearchEndEventMsg",
"type": "object"
},
{
"description": "Notification that the server is about to execute a command.",
"properties": {
"call_id": {
"description": "Identifier so this can be paired with the ExecCommandEnd event.",
"type": "string"
},
"command": {
"description": "The command to be executed.",
"items": {
"type": "string"
},
"type": "array"
},
"cwd": {
"description": "The command's working directory if not the default cwd for the agent.",
"type": "string"
},
"interaction_input": {
"description": "Raw input sent to a unified exec session (if this is an interaction event).",
"type": [
"string",
"null"
]
},
"parsed_cmd": {
"items": {
"$ref": "#/definitions/ParsedCommand"
},
"type": "array"
},
"process_id": {
"description": "Identifier for the underlying PTY process (when available).",
"type": [
"string",
"null"
]
},
"source": {
"allOf": [
{
"$ref": "#/definitions/ExecCommandSource"
}
],
"default": "agent",
"description": "Where the command originated. Defaults to Agent for backward compatibility."
},
"turn_id": {
"description": "Turn ID that this command belongs to.",
"type": "string"
},
"type": {
"enum": [
"exec_command_begin"
],
"title": "ExecCommandBeginEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"command",
"cwd",
"parsed_cmd",
"turn_id",
"type"
],
"title": "ExecCommandBeginEventMsg",
"type": "object"
},
{
"description": "Incremental chunk of output from a running command.",
"properties": {
"call_id": {
"description": "Identifier for the ExecCommandBegin that produced this chunk.",
"type": "string"
},
"chunk": {
"description": "Raw bytes from the stream (may not be valid UTF-8).",
"type": "string"
},
"stream": {
"allOf": [
{
"$ref": "#/definitions/ExecOutputStream"
}
],
"description": "Which stream produced this chunk."
},
"type": {
"enum": [
"exec_command_output_delta"
],
"title": "ExecCommandOutputDeltaEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"chunk",
"stream",
"type"
],
"title": "ExecCommandOutputDeltaEventMsg",
"type": "object"
},
{
"description": "Terminal interaction for an in-progress command (stdin sent and stdout observed).",
"properties": {
"call_id": {
"description": "Identifier for the ExecCommandBegin that produced this chunk.",
"type": "string"
},
"process_id": {
"description": "Process id associated with the running command.",
"type": "string"
},
"stdin": {
"description": "Stdin sent to the running session.",
"type": "string"
},
"type": {
"enum": [
"terminal_interaction"
],
"title": "TerminalInteractionEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"process_id",
"stdin",
"type"
],
"title": "TerminalInteractionEventMsg",
"type": "object"
},
{
"properties": {
"aggregated_output": {
"default": "",
"description": "Captured aggregated output",
"type": "string"
},
"call_id": {
"description": "Identifier for the ExecCommandBegin that finished.",
"type": "string"
},
"command": {
"description": "The command that was executed.",
"items": {
"type": "string"
},
"type": "array"
},
"cwd": {
"description": "The command's working directory if not the default cwd for the agent.",
"type": "string"
},
"duration": {
"allOf": [
{
"$ref": "#/definitions/Duration"
}
],
"description": "The duration of the command execution."
},
"exit_code": {
"description": "The command's exit code.",
"format": "int32",
"type": "integer"
},
"formatted_output": {
"description": "Formatted output from the command, as seen by the model.",
"type": "string"
},
"interaction_input": {
"description": "Raw input sent to a unified exec session (if this is an interaction event).",
"type": [
"string",
"null"
]
},
"parsed_cmd": {
"items": {
"$ref": "#/definitions/ParsedCommand"
},
"type": "array"
},
"process_id": {
"description": "Identifier for the underlying PTY process (when available).",
"type": [
"string",
"null"
]
},
"source": {
"allOf": [
{
"$ref": "#/definitions/ExecCommandSource"
}
],
"default": "agent",
"description": "Where the command originated. Defaults to Agent for backward compatibility."
},
"stderr": {
"description": "Captured stderr",
"type": "string"
},
"stdout": {
"description": "Captured stdout",
"type": "string"
},
"turn_id": {
"description": "Turn ID that this command belongs to.",
"type": "string"
},
"type": {
"enum": [
"exec_command_end"
],
"title": "ExecCommandEndEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"command",
"cwd",
"duration",
"exit_code",
"formatted_output",
"parsed_cmd",
"stderr",
"stdout",
"turn_id",
"type"
],
"title": "ExecCommandEndEventMsg",
"type": "object"
},
{
"description": "Notification that the agent attached a local image via the view_image tool.",
"properties": {
"call_id": {
"description": "Identifier for the originating tool call.",
"type": "string"
},
"path": {
"description": "Local filesystem path provided to the tool.",
"type": "string"
},
"type": {
"enum": [
"view_image_tool_call"
],
"title": "ViewImageToolCallEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"path",
"type"
],
"title": "ViewImageToolCallEventMsg",
"type": "object"
},
{
"properties": {
"call_id": {
"description": "Identifier for the associated exec call, if available.",
"type": "string"
},
"command": {
"description": "The command to be executed.",
"items": {
"type": "string"
},
"type": "array"
},
"cwd": {
"description": "The command's working directory.",
"type": "string"
},
"parsed_cmd": {
"items": {
"$ref": "#/definitions/ParsedCommand"
},
"type": "array"
},
"proposed_execpolicy_amendment": {
"description": "Proposed execpolicy amendment that can be applied to allow future runs.",
"items": {
"type": "string"
},
"type": [
"array",
"null"
]
},
"reason": {
"description": "Optional human-readable reason for the approval (e.g. retry without sandbox).",
"type": [
"string",
"null"
]
},
"turn_id": {
"default": "",
"description": "Turn ID that this command belongs to. Uses `#[serde(default)]` for backwards compatibility.",
"type": "string"
},
"type": {
"enum": [
"exec_approval_request"
],
"title": "ExecApprovalRequestEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"command",
"cwd",
"parsed_cmd",
"type"
],
"title": "ExecApprovalRequestEventMsg",
"type": "object"
},
{
"properties": {
"call_id": {
"description": "Responses API call id for the associated tool call, if available.",
"type": "string"
},
"questions": {
"items": {
"$ref": "#/definitions/RequestUserInputQuestion"
},
"type": "array"
},
"turn_id": {
"default": "",
"description": "Turn ID that this request belongs to. Uses `#[serde(default)]` for backwards compatibility.",
"type": "string"
},
"type": {
"enum": [
"request_user_input"
],
"title": "RequestUserInputEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"questions",
"type"
],
"title": "RequestUserInputEventMsg",
"type": "object"
},
{
"properties": {
"arguments": true,
"callId": {
"type": "string"
},
"tool": {
"type": "string"
},
"turnId": {
"type": "string"
},
"type": {
"enum": [
"dynamic_tool_call_request"
],
"title": "DynamicToolCallRequestEventMsgType",
"type": "string"
}
},
"required": [
"arguments",
"callId",
"tool",
"turnId",
"type"
],
"title": "DynamicToolCallRequestEventMsg",
"type": "object"
},
{
"properties": {
"id": {
"$ref": "#/definitions/RequestId"
},
"message": {
"type": "string"
},
"server_name": {
"type": "string"
},
"type": {
"enum": [
"elicitation_request"
],
"title": "ElicitationRequestEventMsgType",
"type": "string"
}
},
"required": [
"id",
"message",
"server_name",
"type"
],
"title": "ElicitationRequestEventMsg",
"type": "object"
},
{
"properties": {
"call_id": {
"description": "Responses API call id for the associated patch apply call, if available.",
"type": "string"
},
"changes": {
"additionalProperties": {
"$ref": "#/definitions/FileChange"
},
"type": "object"
},
"grant_root": {
"description": "When set, the agent is asking the user to allow writes under this root for the remainder of the session.",
"type": [
"string",
"null"
]
},
"reason": {
"description": "Optional explanatory reason (e.g. request for extra write access).",
"type": [
"string",
"null"
]
},
"turn_id": {
"default": "",
"description": "Turn ID that this patch belongs to. Uses `#[serde(default)]` for backwards compatibility with older senders.",
"type": "string"
},
"type": {
"enum": [
"apply_patch_approval_request"
],
"title": "ApplyPatchApprovalRequestEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"changes",
"type"
],
"title": "ApplyPatchApprovalRequestEventMsg",
"type": "object"
},
{
"description": "Notification advising the user that something they are using has been deprecated and should be phased out.",
"properties": {
"details": {
"description": "Optional extra guidance, such as migration steps or rationale.",
"type": [
"string",
"null"
]
},
"summary": {
"description": "Concise summary of what is deprecated.",
"type": "string"
},
"type": {
"enum": [
"deprecation_notice"
],
"title": "DeprecationNoticeEventMsgType",
"type": "string"
}
},
"required": [
"summary",
"type"
],
"title": "DeprecationNoticeEventMsg",
"type": "object"
},
{
"properties": {
"message": {
"type": "string"
},
"type": {
"enum": [
"background_event"
],
"title": "BackgroundEventEventMsgType",
"type": "string"
}
},
"required": [
"message",
"type"
],
"title": "BackgroundEventEventMsg",
"type": "object"
},
{
"properties": {
"message": {
"type": [
"string",
"null"
]
},
"type": {
"enum": [
"undo_started"
],
"title": "UndoStartedEventMsgType",
"type": "string"
}
},
"required": [
"type"
],
"title": "UndoStartedEventMsg",
"type": "object"
},
{
"properties": {
"message": {
"type": [
"string",
"null"
]
},
"success": {
"type": "boolean"
},
"type": {
"enum": [
"undo_completed"
],
"title": "UndoCompletedEventMsgType",
"type": "string"
}
},
"required": [
"success",
"type"
],
"title": "UndoCompletedEventMsg",
"type": "object"
},
{
"description": "Notification that a model stream experienced an error or disconnect and the system is handling it (e.g., retrying with backoff).",
"properties": {
"additional_details": {
"default": null,
"description": "Optional details about the underlying stream failure (often the same human-readable message that is surfaced as the terminal error if retries are exhausted).",
"type": [
"string",
"null"
]
},
"codex_error_info": {
"anyOf": [
{
"$ref": "#/definitions/CodexErrorInfo2"
},
{
"type": "null"
}
],
"default": null
},
"message": {
"type": "string"
},
"type": {
"enum": [
"stream_error"
],
"title": "StreamErrorEventMsgType",
"type": "string"
}
},
"required": [
"message",
"type"
],
"title": "StreamErrorEventMsg",
"type": "object"
},
{
"description": "Notification that the agent is about to apply a code patch. Mirrors `ExecCommandBegin` so front‑ends can show progress indicators.",
"properties": {
"auto_approved": {
"description": "If true, there was no ApplyPatchApprovalRequest for this patch.",
"type": "boolean"
},
"call_id": {
"description": "Identifier so this can be paired with the PatchApplyEnd event.",
"type": "string"
},
"changes": {
"additionalProperties": {
"$ref": "#/definitions/FileChange"
},
"description": "The changes to be applied.",
"type": "object"
},
"turn_id": {
"default": "",
"description": "Turn ID that this patch belongs to. Uses `#[serde(default)]` for backwards compatibility.",
"type": "string"
},
"type": {
"enum": [
"patch_apply_begin"
],
"title": "PatchApplyBeginEventMsgType",
"type": "string"
}
},
"required": [
"auto_approved",
"call_id",
"changes",
"type"
],
"title": "PatchApplyBeginEventMsg",
"type": "object"
},
{
"description": "Notification that a patch application has finished.",
"properties": {
"call_id": {
"description": "Identifier for the PatchApplyBegin that finished.",
"type": "string"
},
"changes": {
"additionalProperties": {
"$ref": "#/definitions/FileChange"
},
"default": {},
"description": "The changes that were applied (mirrors PatchApplyBeginEvent::changes).",
"type": "object"
},
"stderr": {
"description": "Captured stderr (parser errors, IO failures, etc.).",
"type": "string"
},
"stdout": {
"description": "Captured stdout (summary printed by apply_patch).",
"type": "string"
},
"success": {
"description": "Whether the patch was applied successfully.",
"type": "boolean"
},
"turn_id": {
"default": "",
"description": "Turn ID that this patch belongs to. Uses `#[serde(default)]` for backwards compatibility.",
"type": "string"
},
"type": {
"enum": [
"patch_apply_end"
],
"title": "PatchApplyEndEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"stderr",
"stdout",
"success",
"type"
],
"title": "PatchApplyEndEventMsg",
"type": "object"
},
{
"properties": {
"type": {
"enum": [
"turn_diff"
],
"title": "TurnDiffEventMsgType",
"type": "string"
},
"unified_diff": {
"type": "string"
}
},
"required": [
"type",
"unified_diff"
],
"title": "TurnDiffEventMsg",
"type": "object"
},
{
"description": "Response to GetHistoryEntryRequest.",
"properties": {
"entry": {
"anyOf": [
{
"$ref": "#/definitions/HistoryEntry"
},
{
"type": "null"
}
],
"description": "The entry at the requested offset, if available and parseable."
},
"log_id": {
"format": "uint64",
"minimum": 0.0,
"type": "integer"
},
"offset": {
"format": "uint",
"minimum": 0.0,
"type": "integer"
},
"type": {
"enum": [
"get_history_entry_response"
],
"title": "GetHistoryEntryResponseEventMsgType",
"type": "string"
}
},
"required": [
"log_id",
"offset",
"type"
],
"title": "GetHistoryEntryResponseEventMsg",
"type": "object"
},
{
"description": "List of MCP tools available to the agent.",
"properties": {
"auth_statuses": {
"additionalProperties": {
"$ref": "#/definitions/McpAuthStatus"
},
"description": "Authentication status for each configured MCP server.",
"type": "object"
},
"resource_templates": {
"additionalProperties": {
"items": {
"$ref": "#/definitions/ResourceTemplate"
},
"type": "array"
},
"description": "Known resource templates grouped by server name.",
"type": "object"
},
"resources": {
"additionalProperties": {
"items": {
"$ref": "#/definitions/Resource"
},
"type": "array"
},
"description": "Known resources grouped by server name.",
"type": "object"
},
"tools": {
"additionalProperties": {
"$ref": "#/definitions/Tool"
},
"description": "Fully qualified tool name -> tool definition.",
"type": "object"
},
"type": {
"enum": [
"mcp_list_tools_response"
],
"title": "McpListToolsResponseEventMsgType",
"type": "string"
}
},
"required": [
"auth_statuses",
"resource_templates",
"resources",
"tools",
"type"
],
"title": "McpListToolsResponseEventMsg",
"type": "object"
},
{
"description": "List of custom prompts available to the agent.",
"properties": {
"custom_prompts": {
"items": {
"$ref": "#/definitions/CustomPrompt"
},
"type": "array"
},
"type": {
"enum": [
"list_custom_prompts_response"
],
"title": "ListCustomPromptsResponseEventMsgType",
"type": "string"
}
},
"required": [
"custom_prompts",
"type"
],
"title": "ListCustomPromptsResponseEventMsg",
"type": "object"
},
{
"description": "List of skills available to the agent.",
"properties": {
"skills": {
"items": {
"$ref": "#/definitions/SkillsListEntry"
},
"type": "array"
},
"type": {
"enum": [
"list_skills_response"
],
"title": "ListSkillsResponseEventMsgType",
"type": "string"
}
},
"required": [
"skills",
"type"
],
"title": "ListSkillsResponseEventMsg",
"type": "object"
},
feat: add APIs to list and download public remote skills (#10448) Add API to list / download from remote public skills
2026-02-03 14:09:37 -08:00
{
"description": "List of remote skills available to the agent.",
"properties": {
"skills": {
"items": {
"$ref": "#/definitions/RemoteSkillSummary"
},
"type": "array"
},
"type": {
"enum": [
"list_remote_skills_response"
],
"title": "ListRemoteSkillsResponseEventMsgType",
"type": "string"
}
},
"required": [
"skills",
"type"
],
"title": "ListRemoteSkillsResponseEventMsg",
"type": "object"
},
{
"description": "Remote skill downloaded to local cache.",
"properties": {
"id": {
"type": "string"
},
"name": {
"type": "string"
},
"path": {
"type": "string"
},
"type": {
"enum": [
"remote_skill_downloaded"
],
"title": "RemoteSkillDownloadedEventMsgType",
"type": "string"
}
},
"required": [
"id",
"name",
"path",
"type"
],
"title": "RemoteSkillDownloadedEventMsg",
"type": "object"
},
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
{
"description": "Notification that skill data may have been updated and clients may want to reload.",
"properties": {
"type": {
"enum": [
"skills_update_available"
],
"title": "SkillsUpdateAvailableEventMsgType",
"type": "string"
}
},
"required": [
"type"
],
"title": "SkillsUpdateAvailableEventMsg",
"type": "object"
},
{
"properties": {
"explanation": {
"default": null,
"description": "Arguments for the `update_plan` todo/checklist tool (not plan mode).",
"type": [
"string",
"null"
]
},
"plan": {
"items": {
"$ref": "#/definitions/PlanItemArg"
},
"type": "array"
},
"type": {
"enum": [
"plan_update"
],
"title": "PlanUpdateEventMsgType",
"type": "string"
}
},
"required": [
"plan",
"type"
],
"title": "PlanUpdateEventMsg",
"type": "object"
},
{
"properties": {
"reason": {
"$ref": "#/definitions/TurnAbortReason"
},
"type": {
"enum": [
"turn_aborted"
],
"title": "TurnAbortedEventMsgType",
"type": "string"
}
},
"required": [
"reason",
"type"
],
"title": "TurnAbortedEventMsg",
"type": "object"
},
{
"description": "Notification that the agent is shutting down.",
"properties": {
"type": {
"enum": [
"shutdown_complete"
],
"title": "ShutdownCompleteEventMsgType",
"type": "string"
}
},
"required": [
"type"
],
"title": "ShutdownCompleteEventMsg",
"type": "object"
},
{
"description": "Entered review mode.",
"properties": {
"target": {
"$ref": "#/definitions/ReviewTarget"
},
"type": {
"enum": [
"entered_review_mode"
],
"title": "EnteredReviewModeEventMsgType",
"type": "string"
},
"user_facing_hint": {
"type": [
"string",
"null"
]
}
},
"required": [
"target",
"type"
],
"title": "EnteredReviewModeEventMsg",
"type": "object"
},
{
"description": "Exited review mode with an optional final result to apply.",
"properties": {
"review_output": {
"anyOf": [
{
"$ref": "#/definitions/ReviewOutputEvent"
},
{
"type": "null"
}
]
},
"type": {
"enum": [
"exited_review_mode"
],
"title": "ExitedReviewModeEventMsgType",
"type": "string"
}
},
"required": [
"type"
],
"title": "ExitedReviewModeEventMsg",
"type": "object"
},
{
"properties": {
"item": {
"$ref": "#/definitions/ResponseItem"
},
"type": {
"enum": [
"raw_response_item"
],
"title": "RawResponseItemEventMsgType",
"type": "string"
}
},
"required": [
"item",
"type"
],
"title": "RawResponseItemEventMsg",
"type": "object"
},
{
"properties": {
"item": {
"$ref": "#/definitions/TurnItem"
},
"thread_id": {
"$ref": "#/definitions/ThreadId"
},
"turn_id": {
"type": "string"
},
"type": {
"enum": [
"item_started"
],
"title": "ItemStartedEventMsgType",
"type": "string"
}
},
"required": [
"item",
"thread_id",
"turn_id",
"type"
],
"title": "ItemStartedEventMsg",
"type": "object"
},
{
"properties": {
"item": {
"$ref": "#/definitions/TurnItem"
},
"thread_id": {
"$ref": "#/definitions/ThreadId"
},
"turn_id": {
"type": "string"
},
"type": {
"enum": [
"item_completed"
],
"title": "ItemCompletedEventMsgType",
"type": "string"
}
},
"required": [
"item",
"thread_id",
"turn_id",
"type"
],
"title": "ItemCompletedEventMsg",
"type": "object"
},
{
"properties": {
"delta": {
"type": "string"
},
"item_id": {
"type": "string"
},
"thread_id": {
"type": "string"
},
"turn_id": {
"type": "string"
},
"type": {
"enum": [
"agent_message_content_delta"
],
"title": "AgentMessageContentDeltaEventMsgType",
"type": "string"
}
},
"required": [
"delta",
"item_id",
"thread_id",
"turn_id",
"type"
],
"title": "AgentMessageContentDeltaEventMsg",
"type": "object"
},
{
"properties": {
"delta": {
"type": "string"
},
"item_id": {
"type": "string"
},
"thread_id": {
"type": "string"
},
"turn_id": {
"type": "string"
},
"type": {
"enum": [
"plan_delta"
],
"title": "PlanDeltaEventMsgType",
"type": "string"
}
},
"required": [
"delta",
"item_id",
"thread_id",
"turn_id",
"type"
],
"title": "PlanDeltaEventMsg",
"type": "object"
},
{
"properties": {
"delta": {
"type": "string"
},
"item_id": {
"type": "string"
},
"summary_index": {
"default": 0,
"format": "int64",
"type": "integer"
},
"thread_id": {
"type": "string"
},
"turn_id": {
"type": "string"
},
"type": {
"enum": [
"reasoning_content_delta"
],
"title": "ReasoningContentDeltaEventMsgType",
"type": "string"
}
},
"required": [
"delta",
"item_id",
"thread_id",
"turn_id",
"type"
],
"title": "ReasoningContentDeltaEventMsg",
"type": "object"
},
{
"properties": {
"content_index": {
"default": 0,
"format": "int64",
"type": "integer"
},
"delta": {
"type": "string"
},
"item_id": {
"type": "string"
},
"thread_id": {
"type": "string"
},
"turn_id": {
"type": "string"
},
"type": {
"enum": [
"reasoning_raw_content_delta"
],
"title": "ReasoningRawContentDeltaEventMsgType",
"type": "string"
}
},
"required": [
"delta",
"item_id",
"thread_id",
"turn_id",
"type"
],
"title": "ReasoningRawContentDeltaEventMsg",
"type": "object"
},
{
"description": "Collab interaction: agent spawn begin.",
"properties": {
"call_id": {
"description": "Identifier for the collab tool call.",
"type": "string"
},
"prompt": {
"description": "Initial prompt sent to the agent. Can be empty to prevent CoT leaking at the beginning.",
"type": "string"
},
"sender_thread_id": {
"allOf": [
{
"$ref": "#/definitions/ThreadId"
}
],
"description": "Thread ID of the sender."
},
"type": {
"enum": [
"collab_agent_spawn_begin"
],
"title": "CollabAgentSpawnBeginEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"prompt",
"sender_thread_id",
"type"
],
"title": "CollabAgentSpawnBeginEventMsg",
"type": "object"
},
{
"description": "Collab interaction: agent spawn end.",
"properties": {
"call_id": {
"description": "Identifier for the collab tool call.",
"type": "string"
},
"new_thread_id": {
"anyOf": [
{
"$ref": "#/definitions/ThreadId"
},
{
"type": "null"
}
],
"description": "Thread ID of the newly spawned agent, if it was created."
},
"prompt": {
"description": "Initial prompt sent to the agent. Can be empty to prevent CoT leaking at the beginning.",
"type": "string"
},
"sender_thread_id": {
"allOf": [
{
"$ref": "#/definitions/ThreadId"
}
],
"description": "Thread ID of the sender."
},
"status": {
"allOf": [
{
"$ref": "#/definitions/AgentStatus"
}
],
"description": "Last known status of the new agent reported to the sender agent."
},
"type": {
"enum": [
"collab_agent_spawn_end"
],
"title": "CollabAgentSpawnEndEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"prompt",
"sender_thread_id",
"status",
"type"
],
"title": "CollabAgentSpawnEndEventMsg",
"type": "object"
},
{
"description": "Collab interaction: agent interaction begin.",
"properties": {
"call_id": {
"description": "Identifier for the collab tool call.",
"type": "string"
},
"prompt": {
"description": "Prompt sent from the sender to the receiver. Can be empty to prevent CoT leaking at the beginning.",
"type": "string"
},
"receiver_thread_id": {
"allOf": [
{
"$ref": "#/definitions/ThreadId"
}
],
"description": "Thread ID of the receiver."
},
"sender_thread_id": {
"allOf": [
{
"$ref": "#/definitions/ThreadId"
}
],
"description": "Thread ID of the sender."
},
"type": {
"enum": [
"collab_agent_interaction_begin"
],
"title": "CollabAgentInteractionBeginEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"prompt",
"receiver_thread_id",
"sender_thread_id",
"type"
],
"title": "CollabAgentInteractionBeginEventMsg",
"type": "object"
},
{
"description": "Collab interaction: agent interaction end.",
"properties": {
"call_id": {
"description": "Identifier for the collab tool call.",
"type": "string"
},
"prompt": {
"description": "Prompt sent from the sender to the receiver. Can be empty to prevent CoT leaking at the beginning.",
"type": "string"
},
"receiver_thread_id": {
"allOf": [
{
"$ref": "#/definitions/ThreadId"
}
],
"description": "Thread ID of the receiver."
},
"sender_thread_id": {
"allOf": [
{
"$ref": "#/definitions/ThreadId"
}
],
"description": "Thread ID of the sender."
},
"status": {
"allOf": [
{
"$ref": "#/definitions/AgentStatus"
}
],
"description": "Last known status of the receiver agent reported to the sender agent."
},
"type": {
"enum": [
"collab_agent_interaction_end"
],
"title": "CollabAgentInteractionEndEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"prompt",
"receiver_thread_id",
"sender_thread_id",
"status",
"type"
],
"title": "CollabAgentInteractionEndEventMsg",
"type": "object"
},
{
"description": "Collab interaction: waiting begin.",
"properties": {
"call_id": {
"description": "ID of the waiting call.",
"type": "string"
},
"receiver_thread_ids": {
"description": "Thread ID of the receivers.",
"items": {
"$ref": "#/definitions/ThreadId"
},
"type": "array"
},
"sender_thread_id": {
"allOf": [
{
"$ref": "#/definitions/ThreadId"
}
],
"description": "Thread ID of the sender."
},
"type": {
"enum": [
"collab_waiting_begin"
],
"title": "CollabWaitingBeginEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"receiver_thread_ids",
"sender_thread_id",
"type"
],
"title": "CollabWaitingBeginEventMsg",
"type": "object"
},
{
"description": "Collab interaction: waiting end.",
"properties": {
"call_id": {
"description": "ID of the waiting call.",
"type": "string"
},
"sender_thread_id": {
"allOf": [
{
"$ref": "#/definitions/ThreadId"
}
],
"description": "Thread ID of the sender."
},
"statuses": {
"additionalProperties": {
"$ref": "#/definitions/AgentStatus"
},
"description": "Last known status of the receiver agents reported to the sender agent.",
"type": "object"
},
"type": {
"enum": [
"collab_waiting_end"
],
"title": "CollabWaitingEndEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"sender_thread_id",
"statuses",
"type"
],
"title": "CollabWaitingEndEventMsg",
"type": "object"
},
{
"description": "Collab interaction: close begin.",
"properties": {
"call_id": {
"description": "Identifier for the collab tool call.",
"type": "string"
},
"receiver_thread_id": {
"allOf": [
{
"$ref": "#/definitions/ThreadId"
}
],
"description": "Thread ID of the receiver."
},
"sender_thread_id": {
"allOf": [
{
"$ref": "#/definitions/ThreadId"
}
],
"description": "Thread ID of the sender."
},
"type": {
"enum": [
"collab_close_begin"
],
"title": "CollabCloseBeginEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"receiver_thread_id",
"sender_thread_id",
"type"
],
"title": "CollabCloseBeginEventMsg",
"type": "object"
},
{
"description": "Collab interaction: close end.",
"properties": {
"call_id": {
"description": "Identifier for the collab tool call.",
"type": "string"
},
"receiver_thread_id": {
"allOf": [
{
"$ref": "#/definitions/ThreadId"
}
],
"description": "Thread ID of the receiver."
},
"sender_thread_id": {
"allOf": [
{
"$ref": "#/definitions/ThreadId"
}
],
"description": "Thread ID of the sender."
},
"status": {
"allOf": [
{
"$ref": "#/definitions/AgentStatus"
}
],
"description": "Last known status of the receiver agent reported to the sender agent before the close."
},
"type": {
"enum": [
"collab_close_end"
],
"title": "CollabCloseEndEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"receiver_thread_id",
"sender_thread_id",
"status",
"type"
],
"title": "CollabCloseEndEventMsg",
"type": "object"
Add resume_agent collab tool (#10903) Summary - add the new resume_agent collab tool path through core, protocol, and the app server API, including the resume events - update the schema/TypeScript definitions plus docs so resume_agent appears in generated artifacts and README - note that resumed agents rehydrate rollout history without overwriting their base instructions Testing - Not run (not requested)
2026-02-07 17:31:45 +01:00
},
{
"description": "Collab interaction: resume begin.",
"properties": {
"call_id": {
"description": "Identifier for the collab tool call.",
"type": "string"
},
"receiver_thread_id": {
"allOf": [
{
"$ref": "#/definitions/ThreadId"
}
],
"description": "Thread ID of the receiver."
},
"sender_thread_id": {
"allOf": [
{
"$ref": "#/definitions/ThreadId"
}
],
"description": "Thread ID of the sender."
},
"type": {
"enum": [
"collab_resume_begin"
],
"title": "CollabResumeBeginEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"receiver_thread_id",
"sender_thread_id",
"type"
],
"title": "CollabResumeBeginEventMsg",
"type": "object"
},
{
"description": "Collab interaction: resume end.",
"properties": {
"call_id": {
"description": "Identifier for the collab tool call.",
"type": "string"
},
"receiver_thread_id": {
"allOf": [
{
"$ref": "#/definitions/ThreadId"
}
],
"description": "Thread ID of the receiver."
},
"sender_thread_id": {
"allOf": [
{
"$ref": "#/definitions/ThreadId"
}
],
"description": "Thread ID of the sender."
},
"status": {
"allOf": [
{
"$ref": "#/definitions/AgentStatus"
}
],
"description": "Last known status of the receiver agent reported to the sender agent after resume."
},
"type": {
"enum": [
"collab_resume_end"
],
"title": "CollabResumeEndEventMsgType",
"type": "string"
}
},
"required": [
"call_id",
"receiver_thread_id",
"sender_thread_id",
"status",
"type"
],
"title": "CollabResumeEndEventMsg",
"type": "object"
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
}
]
},
"ExecCommandSource": {
"enum": [
"agent",
"user_shell",
"unified_exec_startup",
"unified_exec_interaction"
],
"type": "string"
},
"ExecOutputStream": {
"enum": [
"stdout",
"stderr"
],
"type": "string"
},
"FileChange": {
"oneOf": [
{
"properties": {
"content": {
"type": "string"
},
"type": {
"enum": [
"add"
],
"title": "AddFileChangeType",
"type": "string"
}
},
"required": [
"content",
"type"
],
"title": "AddFileChange",
"type": "object"
},
{
"properties": {
"content": {
"type": "string"
},
"type": {
"enum": [
"delete"
],
"title": "DeleteFileChangeType",
"type": "string"
}
},
"required": [
"content",
"type"
],
"title": "DeleteFileChange",
"type": "object"
},
{
"properties": {
"move_path": {
"type": [
"string",
"null"
]
},
"type": {
"enum": [
"update"
],
"title": "UpdateFileChangeType",
"type": "string"
},
"unified_diff": {
"type": "string"
}
},
"required": [
"type",
"unified_diff"
],
"title": "UpdateFileChange",
"type": "object"
}
]
},
"FileChangeOutputDeltaNotification": {
"properties": {
"delta": {
"type": "string"
},
"itemId": {
"type": "string"
},
"threadId": {
"type": "string"
},
"turnId": {
"type": "string"
}
},
"required": [
"delta",
"itemId",
"threadId",
"turnId"
],
"type": "object"
},
"FileUpdateChange": {
"properties": {
"diff": {
"type": "string"
},
"kind": {
"$ref": "#/definitions/PatchChangeKind"
},
"path": {
"type": "string"
}
},
"required": [
"diff",
"kind",
"path"
],
"type": "object"
},
feat(app-server, core): allow text + image content items for dynamic tool outputs (#10567) Took over the work that @aaronl-openai started here: https://github.com/openai/codex/pull/10397 Now that app-server clients are able to set up custom tools (called `dynamic_tools` in app-server), we should expose a way for clients to pass in not just text, but also image outputs. This is something the Responses API already supports for function call outputs, where you can pass in either a string or an array of content outputs (text, image, file): https://platform.openai.com/docs/api-reference/responses/create#responses_create-input-input_item_list-item-function_tool_call_output-output-array-input_image So let's just plumb it through in Codex (with the caveat that we only support text and image for now). This is implemented end-to-end across app-server v2 protocol types and core tool handling. ## Breaking API change NOTE: This introduces a breaking change with dynamic tools, but I think it's ok since this concept was only recently introduced (https://github.com/openai/codex/pull/9539) and it's better to get the API contract correct. I don't think there are any real consumers of this yet (not even the Codex App). Old shape: `{ "output": "dynamic-ok", "success": true }` New shape: ``` { "contentItems": [ { "type": "inputText", "text": "dynamic-ok" }, { "type": "inputImage", "imageUrl": "data:image/png;base64,AAA" } ] "success": true } ```
2026-02-04 16:12:47 -08:00
"FunctionCallOutputBody": {
"anyOf": [
{
"type": "string"
},
{
"items": {
"$ref": "#/definitions/FunctionCallOutputContentItem"
},
"type": "array"
}
]
},
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
"FunctionCallOutputContentItem": {
"description": "Responses API compatible content items that can be returned by a tool call. This is a subset of ContentItem with the types we support as function call outputs.",
"oneOf": [
{
"properties": {
"text": {
"type": "string"
},
"type": {
"enum": [
"input_text"
],
"title": "InputTextFunctionCallOutputContentItemType",
"type": "string"
}
},
"required": [
"text",
"type"
],
"title": "InputTextFunctionCallOutputContentItem",
"type": "object"
},
{
"properties": {
"image_url": {
"type": "string"
},
"type": {
"enum": [
"input_image"
],
"title": "InputImageFunctionCallOutputContentItemType",
"type": "string"
}
},
"required": [
"image_url",
"type"
],
"title": "InputImageFunctionCallOutputContentItem",
"type": "object"
}
]
},
"FunctionCallOutputPayload": {
feat(app-server, core): allow text + image content items for dynamic tool outputs (#10567) Took over the work that @aaronl-openai started here: https://github.com/openai/codex/pull/10397 Now that app-server clients are able to set up custom tools (called `dynamic_tools` in app-server), we should expose a way for clients to pass in not just text, but also image outputs. This is something the Responses API already supports for function call outputs, where you can pass in either a string or an array of content outputs (text, image, file): https://platform.openai.com/docs/api-reference/responses/create#responses_create-input-input_item_list-item-function_tool_call_output-output-array-input_image So let's just plumb it through in Codex (with the caveat that we only support text and image for now). This is implemented end-to-end across app-server v2 protocol types and core tool handling. ## Breaking API change NOTE: This introduces a breaking change with dynamic tools, but I think it's ok since this concept was only recently introduced (https://github.com/openai/codex/pull/9539) and it's better to get the API contract correct. I don't think there are any real consumers of this yet (not even the Codex App). Old shape: `{ "output": "dynamic-ok", "success": true }` New shape: ``` { "contentItems": [ { "type": "inputText", "text": "dynamic-ok" }, { "type": "inputImage", "imageUrl": "data:image/png;base64,AAA" } ] "success": true } ```
2026-02-04 16:12:47 -08:00
"description": "The payload we send back to OpenAI when reporting a tool call result.\n\n`body` serializes directly as the wire value for `function_call_output.output`. `success` remains internal metadata for downstream handling.",
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
"properties": {
feat(app-server, core): allow text + image content items for dynamic tool outputs (#10567) Took over the work that @aaronl-openai started here: https://github.com/openai/codex/pull/10397 Now that app-server clients are able to set up custom tools (called `dynamic_tools` in app-server), we should expose a way for clients to pass in not just text, but also image outputs. This is something the Responses API already supports for function call outputs, where you can pass in either a string or an array of content outputs (text, image, file): https://platform.openai.com/docs/api-reference/responses/create#responses_create-input-input_item_list-item-function_tool_call_output-output-array-input_image So let's just plumb it through in Codex (with the caveat that we only support text and image for now). This is implemented end-to-end across app-server v2 protocol types and core tool handling. ## Breaking API change NOTE: This introduces a breaking change with dynamic tools, but I think it's ok since this concept was only recently introduced (https://github.com/openai/codex/pull/9539) and it's better to get the API contract correct. I don't think there are any real consumers of this yet (not even the Codex App). Old shape: `{ "output": "dynamic-ok", "success": true }` New shape: ``` { "contentItems": [ { "type": "inputText", "text": "dynamic-ok" }, { "type": "inputImage", "imageUrl": "data:image/png;base64,AAA" } ] "success": true } ```
2026-02-04 16:12:47 -08:00
"body": {
"$ref": "#/definitions/FunctionCallOutputBody"
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
},
"success": {
"type": [
"boolean",
"null"
]
}
},
"required": [
feat(app-server, core): allow text + image content items for dynamic tool outputs (#10567) Took over the work that @aaronl-openai started here: https://github.com/openai/codex/pull/10397 Now that app-server clients are able to set up custom tools (called `dynamic_tools` in app-server), we should expose a way for clients to pass in not just text, but also image outputs. This is something the Responses API already supports for function call outputs, where you can pass in either a string or an array of content outputs (text, image, file): https://platform.openai.com/docs/api-reference/responses/create#responses_create-input-input_item_list-item-function_tool_call_output-output-array-input_image So let's just plumb it through in Codex (with the caveat that we only support text and image for now). This is implemented end-to-end across app-server v2 protocol types and core tool handling. ## Breaking API change NOTE: This introduces a breaking change with dynamic tools, but I think it's ok since this concept was only recently introduced (https://github.com/openai/codex/pull/9539) and it's better to get the API contract correct. I don't think there are any real consumers of this yet (not even the Codex App). Old shape: `{ "output": "dynamic-ok", "success": true }` New shape: ``` { "contentItems": [ { "type": "inputText", "text": "dynamic-ok" }, { "type": "inputImage", "imageUrl": "data:image/png;base64,AAA" } ] "success": true } ```
2026-02-04 16:12:47 -08:00
"body"
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
],
"type": "object"
},
"GhostCommit": {
"description": "Details of a ghost commit created from a repository state.",
"properties": {
"id": {
"type": "string"
},
"parent": {
"type": [
"string",
"null"
]
},
"preexisting_untracked_dirs": {
"items": {
"type": "string"
},
"type": "array"
},
"preexisting_untracked_files": {
"items": {
"type": "string"
},
"type": "array"
}
},
"required": [
"id",
"preexisting_untracked_dirs",
"preexisting_untracked_files"
],
"type": "object"
},
"GitInfo": {
"properties": {
"branch": {
"type": [
"string",
"null"
]
},
"originUrl": {
"type": [
"string",
"null"
]
},
"sha": {
"type": [
"string",
"null"
]
}
},
"type": "object"
},
"HistoryEntry": {
"properties": {
"conversation_id": {
"type": "string"
},
"text": {
"type": "string"
},
"ts": {
"format": "uint64",
"minimum": 0.0,
"type": "integer"
}
},
"required": [
"conversation_id",
"text",
"ts"
],
"type": "object"
},
"ItemCompletedNotification": {
"properties": {
"item": {
"$ref": "#/definitions/ThreadItem"
},
"threadId": {
"type": "string"
},
"turnId": {
"type": "string"
}
},
"required": [
"item",
"threadId",
"turnId"
],
"type": "object"
},
"ItemStartedNotification": {
"properties": {
"item": {
"$ref": "#/definitions/ThreadItem"
},
"threadId": {
"type": "string"
},
"turnId": {
"type": "string"
}
},
"required": [
"item",
"threadId",
"turnId"
],
"type": "object"
},
"LocalShellAction": {
"oneOf": [
{
"properties": {
"command": {
"items": {
"type": "string"
},
"type": "array"
},
"env": {
"additionalProperties": {
"type": "string"
},
"type": [
"object",
"null"
]
},
"timeout_ms": {
"format": "uint64",
"minimum": 0.0,
"type": [
"integer",
"null"
]
},
"type": {
"enum": [
"exec"
],
"title": "ExecLocalShellActionType",
"type": "string"
},
"user": {
"type": [
"string",
"null"
]
},
"working_directory": {
"type": [
"string",
"null"
]
}
},
"required": [
"command",
"type"
],
"title": "ExecLocalShellAction",
"type": "object"
}
]
},
"LocalShellStatus": {
"enum": [
"completed",
"in_progress",
"incomplete"
],
"type": "string"
},
"LoginChatGptCompleteNotification": {
"description": "Deprecated in favor of AccountLoginCompletedNotification.",
"properties": {
"error": {
"type": [
"string",
"null"
]
},
"loginId": {
"type": "string"
},
"success": {
"type": "boolean"
}
},
"required": [
"loginId",
"success"
],
"type": "object"
},
"McpAuthStatus": {
"enum": [
"unsupported",
"not_logged_in",
"bearer_token",
"o_auth"
],
"type": "string"
},
"McpInvocation": {
"properties": {
"arguments": {
"description": "Arguments to the tool call."
},
"server": {
"description": "Name of the MCP server as defined in the config.",
"type": "string"
},
"tool": {
"description": "Name of the tool as given by the MCP server.",
"type": "string"
}
},
"required": [
"server",
"tool"
],
"type": "object"
},
"McpServerOauthLoginCompletedNotification": {
"properties": {
"error": {
"type": [
"string",
"null"
]
},
"name": {
"type": "string"
},
"success": {
"type": "boolean"
}
},
"required": [
"name",
"success"
],
"type": "object"
},
"McpStartupFailure": {
"properties": {
"error": {
"type": "string"
},
"server": {
"type": "string"
}
},
"required": [
"error",
"server"
],
"type": "object"
},
"McpStartupStatus": {
"oneOf": [
{
"properties": {
"state": {
"enum": [
"starting"
],
"type": "string"
}
},
"required": [
"state"
],
"title": "StateMcpStartupStatus",
"type": "object"
},
{
"properties": {
"state": {
"enum": [
"ready"
],
"type": "string"
}
},
"required": [
"state"
],
"title": "StateMcpStartupStatus2",
"type": "object"
},
{
"properties": {
"error": {
"type": "string"
},
"state": {
"enum": [
"failed"
],
"type": "string"
}
},
"required": [
"error",
"state"
],
"type": "object"
},
{
"properties": {
"state": {
"enum": [
"cancelled"
],
"type": "string"
}
},
"required": [
"state"
],
"title": "StateMcpStartupStatus3",
"type": "object"
}
]
},
"McpToolCallError": {
"properties": {
"message": {
"type": "string"
}
},
"required": [
"message"
],
"type": "object"
},
"McpToolCallProgressNotification": {
"properties": {
"itemId": {
"type": "string"
},
"message": {
"type": "string"
},
"threadId": {
"type": "string"
},
"turnId": {
"type": "string"
}
},
"required": [
"itemId",
"message",
"threadId",
"turnId"
],
"type": "object"
},
"McpToolCallResult": {
"properties": {
"content": {
feat: replace custom mcp-types crate with equivalents from rmcp (#10349) We started working with MCP in Codex before https://crates.io/crates/rmcp was mature, so we had our own crate for MCP types that was generated from the MCP schema: https://github.com/openai/codex/blob/8b95d3e082376f4cb23e92641705a22afb28a9da/codex-rs/mcp-types/README.md Now that `rmcp` is more mature, it makes more sense to use their MCP types in Rust, as they handle details (like the `_meta` field) that our custom version ignored. Though one advantage that our custom types had is that our generated types implemented `JsonSchema` and `ts_rs::TS`, whereas the types in `rmcp` do not. As such, part of the work of this PR is leveraging the adapters between `rmcp` types and the serializable types that are API for us (app server and MCP) introduced in #10356. Note this PR results in a number of changes to `codex-rs/app-server-protocol/schema`, which merit special attention during review. We must ensure that these changes are still backwards-compatible, which is possible because we have: ```diff - export type CallToolResult = { content: Array<ContentBlock>, isError?: boolean, structuredContent?: JsonValue, }; + export type CallToolResult = { content: Array<JsonValue>, structuredContent?: JsonValue, isError?: boolean, _meta?: JsonValue, }; ``` so `ContentBlock` has been replaced with the more general `JsonValue`. Note that `ContentBlock` was defined as: ```typescript export type ContentBlock = TextContent | ImageContent | AudioContent | ResourceLink | EmbeddedResource; ``` so the deletion of those individual variants should not be a cause of great concern. Similarly, we have the following change in `codex-rs/app-server-protocol/schema/typescript/Tool.ts`: ``` - export type Tool = { annotations?: ToolAnnotations, description?: string, inputSchema: ToolInputSchema, name: string, outputSchema?: ToolOutputSchema, title?: string, }; + export type Tool = { name: string, title?: string, description?: string, inputSchema: JsonValue, outputSchema?: JsonValue, annotations?: JsonValue, icons?: Array<JsonValue>, _meta?: JsonValue, }; ``` so: - `annotations?: ToolAnnotations` ➡️ `JsonValue` - `inputSchema: ToolInputSchema` ➡️ `JsonValue` - `outputSchema?: ToolOutputSchema` ➡️ `JsonValue` and two new fields: `icons?: Array<JsonValue>, _meta?: JsonValue` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10349). * #10357 * __->__ #10349 * #10356
2026-02-02 17:41:55 -08:00
"items": true,
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
"type": "array"
},
"structuredContent": true
},
"required": [
"content"
],
"type": "object"
},
"McpToolCallStatus": {
"enum": [
"inProgress",
"completed",
"failed"
],
"type": "string"
},
chore: add phase to message responseitem (#10455) ### What add wiring for `phase` field on `ResponseItem::Message` to lay groundwork for differentiating model preambles and final messages. currently optional. follows pattern in #9698. updated schemas with `just write-app-server-schema` so we can see type changes. ### Tests Updated existing tests for SSE parsing and hydrating from history
2026-02-02 18:52:26 -08:00
"MessagePhase": {
fix(tui): conditionally restore status indicator using message phase (#10947) TLDR: use new message phase field emitted by preamble-supported models to determine whether an AgentMessage is mid-turn commentary. if so, restore the status indicator afterwards to indicate the turn has not completed. ### Problem `commit_tick` hides the status indicator while streaming assistant text. For preamble-capable models, that text can be commentary mid-turn, so hiding was correct during streaming but restore timing mattered: - restoring too aggressively caused jitter/flashing - not restoring caused indicator to stay hidden before subsequent work (tool calls, web search, etc.) ### Fix - Add optional `phase` to `AgentMessageItem` and propagate it from `ResponseItem::Message` - Keep indicator hidden during streamed commit ticks, restore only when: - assistant item completes as `phase=commentary`, and - stream queues are idle + task is still running. - Treat `phase=None` as final-answer behavior (no restore) to keep existing behavior for non-preamble models ### Tests Add/update tests for: - no idle-tick restore without commentary completion - commentary completion restoring status before tool begin - snapshot coverage for preamble/status behavior --------- Co-authored-by: Josh McKinney <joshka@openai.com>
2026-02-06 18:39:52 -08:00
"description": "Classifies an assistant message as interim commentary or final answer text.\n\nProviders do not emit this consistently, so callers must treat `None` as \"phase unknown\" and keep compatibility behavior for legacy models.",
"oneOf": [
{
"description": "Mid-turn assistant text (for example preamble/progress narration).\n\nAdditional tool calls or assistant output may follow before turn completion.",
"enum": [
"commentary"
],
"type": "string"
},
{
"description": "The assistant's terminal answer text for the current turn.",
"enum": [
"final_answer"
],
"type": "string"
}
]
chore: add phase to message responseitem (#10455) ### What add wiring for `phase` field on `ResponseItem::Message` to lay groundwork for differentiating model preambles and final messages. currently optional. follows pattern in #9698. updated schemas with `just write-app-server-schema` so we can see type changes. ### Tests Updated existing tests for SSE parsing and hydrating from history
2026-02-02 18:52:26 -08:00
},
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
"ModeKind": {
"description": "Initial collaboration mode to use when the TUI starts.",
"enum": [
"plan",
Cleanup collaboration mode variants (#10404) ## Summary This PR simplifies collaboration modes to the visible set `default | plan`, while preserving backward compatibility for older partners that may still send legacy mode names. Specifically: - Renames the old Code behavior to **Default**. - Keeps **Plan** as-is. - Removes **Custom** mode behavior (fallbacks now resolve to Default). - Keeps `PairProgramming` and `Execute` internally for compatibility plumbing, while removing them from schema/API and UI visibility. - Adds legacy input aliasing so older clients can still send old mode names. ## What Changed 1. Mode enum and compatibility - `ModeKind` now uses `Plan` + `Default` as active/public modes. - `ModeKind::Default` deserialization accepts legacy values: - `code` - `pair_programming` - `execute` - `custom` - `PairProgramming` and `Execute` variants remain in code but are hidden from protocol/schema generation. - `Custom` variant is removed; previous custom fallbacks now map to `Default`. 2. Collaboration presets and templates - Built-in presets now return only: - `Plan` - `Default` - Template rename: - `core/templates/collaboration_mode/code.md` -> `default.md` - `execute.md` and `pair_programming.md` remain on disk but are not surfaced in visible preset lists. 3. TUI updates - Updated user-facing naming and prompts from “Code” to “Default”. - Updated mode-cycle and indicator behavior to reflect only visible `Plan` and `Default`. - Updated corresponding tests and snapshots. 4. request_user_input behavior - `request_user_input` remains allowed only in `Plan` mode. - Rejection messaging now consistently treats non-plan modes as `Default`. 5. Schemas - Regenerated config and app-server schemas. - Public schema types now advertise mode values as: - `plan` - `default` ## Backward Compatibility Notes - Incoming legacy mode names (`code`, `pair_programming`, `execute`, `custom`) are accepted and coerced to `default`. - Outgoing/public schema surfaces intentionally expose only `plan | default`. - This allows tolerant ingestion of older partner payloads while standardizing new integrations on the reduced mode set. ## Codex author `codex fork 019c1fae-693b-7840-b16e-9ad38ea0bd00`
2026-02-03 09:23:53 -08:00
"default"
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
],
"type": "string"
},
"NetworkAccess": {
"description": "Represents whether outbound network access is available to the agent.",
"enum": [
"restricted",
"enabled"
],
"type": "string"
},
"ParsedCommand": {
"oneOf": [
{
"properties": {
"cmd": {
"type": "string"
},
"name": {
"type": "string"
},
"path": {
"description": "(Best effort) Path to the file being read by the command. When possible, this is an absolute path, though when relative, it should be resolved against the `cwd`` that will be used to run the command to derive the absolute path.",
"type": "string"
},
"type": {
"enum": [
"read"
],
"title": "ReadParsedCommandType",
"type": "string"
}
},
"required": [
"cmd",
"name",
"path",
"type"
],
"title": "ReadParsedCommand",
"type": "object"
},
{
"properties": {
"cmd": {
"type": "string"
},
"path": {
"type": [
"string",
"null"
]
},
"type": {
"enum": [
"list_files"
],
"title": "ListFilesParsedCommandType",
"type": "string"
}
},
"required": [
"cmd",
"type"
],
"title": "ListFilesParsedCommand",
"type": "object"
},
{
"properties": {
"cmd": {
"type": "string"
},
"path": {
"type": [
"string",
"null"
]
},
"query": {
"type": [
"string",
"null"
]
},
"type": {
"enum": [
"search"
],
"title": "SearchParsedCommandType",
"type": "string"
}
},
"required": [
"cmd",
"type"
],
"title": "SearchParsedCommand",
"type": "object"
},
{
"properties": {
"cmd": {
"type": "string"
},
"type": {
"enum": [
"unknown"
],
"title": "UnknownParsedCommandType",
"type": "string"
}
},
"required": [
"cmd",
"type"
],
"title": "UnknownParsedCommand",
"type": "object"
}
]
},
"PatchApplyStatus": {
"enum": [
"inProgress",
"completed",
"failed",
"declined"
],
"type": "string"
},
"PatchChangeKind": {
"oneOf": [
{
"properties": {
"type": {
"enum": [
"add"
],
"title": "AddPatchChangeKindType",
"type": "string"
}
},
"required": [
"type"
],
"title": "AddPatchChangeKind",
"type": "object"
},
{
"properties": {
"type": {
"enum": [
"delete"
],
"title": "DeletePatchChangeKindType",
"type": "string"
}
},
"required": [
"type"
],
"title": "DeletePatchChangeKind",
"type": "object"
},
{
"properties": {
"move_path": {
"type": [
"string",
"null"
]
},
"type": {
"enum": [
"update"
],
"title": "UpdatePatchChangeKindType",
"type": "string"
}
},
"required": [
"type"
],
"title": "UpdatePatchChangeKind",
"type": "object"
}
]
},
"PlanDeltaNotification": {
"description": "EXPERIMENTAL - proposed plan streaming deltas for plan items. Clients should not assume concatenated deltas match the completed plan item content.",
"properties": {
"delta": {
"type": "string"
},
"itemId": {
"type": "string"
},
"threadId": {
"type": "string"
},
"turnId": {
"type": "string"
}
},
"required": [
"delta",
"itemId",
"threadId",
"turnId"
],
"type": "object"
},
"PlanItemArg": {
"additionalProperties": false,
"properties": {
"status": {
"$ref": "#/definitions/StepStatus"
},
"step": {
"type": "string"
}
},
"required": [
"status",
"step"
],
"type": "object"
},
"PlanType": {
"enum": [
"free",
"go",
"plus",
"pro",
"team",
"business",
"enterprise",
"edu",
"unknown"
],
"type": "string"
},
"RateLimitSnapshot": {
"properties": {
"credits": {
"anyOf": [
{
"$ref": "#/definitions/CreditsSnapshot"
},
{
"type": "null"
}
]
},
"planType": {
"anyOf": [
{
"$ref": "#/definitions/PlanType"
},
{
"type": "null"
}
]
},
"primary": {
"anyOf": [
{
"$ref": "#/definitions/RateLimitWindow"
},
{
"type": "null"
}
]
},
"secondary": {
"anyOf": [
{
"$ref": "#/definitions/RateLimitWindow"
},
{
"type": "null"
}
]
}
},
"type": "object"
},
"RateLimitSnapshot2": {
"properties": {
"credits": {
"anyOf": [
{
"$ref": "#/definitions/CreditsSnapshot2"
},
{
"type": "null"
}
]
},
"plan_type": {
"anyOf": [
{
"$ref": "#/definitions/PlanType"
},
{
"type": "null"
}
]
},
"primary": {
"anyOf": [
{
"$ref": "#/definitions/RateLimitWindow2"
},
{
"type": "null"
}
]
},
"secondary": {
"anyOf": [
{
"$ref": "#/definitions/RateLimitWindow2"
},
{
"type": "null"
}
]
}
},
"type": "object"
},
"RateLimitWindow": {
"properties": {
"resetsAt": {
"format": "int64",
"type": [
"integer",
"null"
]
},
"usedPercent": {
"format": "int32",
"type": "integer"
},
"windowDurationMins": {
"format": "int64",
"type": [
"integer",
"null"
]
}
},
"required": [
"usedPercent"
],
"type": "object"
},
"RateLimitWindow2": {
"properties": {
"resets_at": {
"description": "Unix timestamp (seconds since epoch) when the window resets.",
"format": "int64",
"type": [
"integer",
"null"
]
},
"used_percent": {
"description": "Percentage (0-100) of the window that has been consumed.",
"format": "double",
"type": "number"
},
"window_minutes": {
"description": "Rolling window duration, in minutes.",
"format": "int64",
"type": [
"integer",
"null"
]
}
},
"required": [
"used_percent"
],
"type": "object"
},
"RawResponseItemCompletedNotification": {
"properties": {
"item": {
"$ref": "#/definitions/ResponseItem"
},
"threadId": {
"type": "string"
},
"turnId": {
"type": "string"
}
},
"required": [
"item",
"threadId",
"turnId"
],
"type": "object"
},
"ReasoningEffort": {
"description": "See https://platform.openai.com/docs/guides/reasoning?api-mode=responses#get-started-with-reasoning",
"enum": [
"none",
"minimal",
"low",
"medium",
"high",
"xhigh"
],
"type": "string"
},
"ReasoningItemContent": {
"oneOf": [
{
"properties": {
"text": {
"type": "string"
},
"type": {
"enum": [
"reasoning_text"
],
"title": "ReasoningTextReasoningItemContentType",
"type": "string"
}
},
"required": [
"text",
"type"
],
"title": "ReasoningTextReasoningItemContent",
"type": "object"
},
{
"properties": {
"text": {
"type": "string"
},
"type": {
"enum": [
"text"
],
"title": "TextReasoningItemContentType",
"type": "string"
}
},
"required": [
"text",
"type"
],
"title": "TextReasoningItemContent",
"type": "object"
}
]
},
"ReasoningItemReasoningSummary": {
"oneOf": [
{
"properties": {
"text": {
"type": "string"
},
"type": {
"enum": [
"summary_text"
],
"title": "SummaryTextReasoningItemReasoningSummaryType",
"type": "string"
}
},
"required": [
"text",
"type"
],
"title": "SummaryTextReasoningItemReasoningSummary",
"type": "object"
}
]
},
"ReasoningSummaryPartAddedNotification": {
"properties": {
"itemId": {
"type": "string"
},
"summaryIndex": {
"format": "int64",
"type": "integer"
},
"threadId": {
"type": "string"
},
"turnId": {
"type": "string"
}
},
"required": [
"itemId",
"summaryIndex",
"threadId",
"turnId"
],
"type": "object"
},
"ReasoningSummaryTextDeltaNotification": {
"properties": {
"delta": {
"type": "string"
},
"itemId": {
"type": "string"
},
"summaryIndex": {
"format": "int64",
"type": "integer"
},
"threadId": {
"type": "string"
},
"turnId": {
"type": "string"
}
},
"required": [
"delta",
"itemId",
"summaryIndex",
"threadId",
"turnId"
],
"type": "object"
},
"ReasoningTextDeltaNotification": {
"properties": {
"contentIndex": {
"format": "int64",
"type": "integer"
},
"delta": {
"type": "string"
},
"itemId": {
"type": "string"
},
"threadId": {
"type": "string"
},
"turnId": {
"type": "string"
}
},
"required": [
"contentIndex",
"delta",
"itemId",
"threadId",
"turnId"
],
"type": "object"
},
feat: add APIs to list and download public remote skills (#10448) Add API to list / download from remote public skills
2026-02-03 14:09:37 -08:00
"RemoteSkillSummary": {
"properties": {
"description": {
"type": "string"
},
"id": {
"type": "string"
},
"name": {
"type": "string"
}
},
"required": [
"description",
"id",
"name"
],
"type": "object"
},
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
"RequestId": {
"anyOf": [
{
"type": "string"
},
{
"format": "int64",
"type": "integer"
}
feat: replace custom mcp-types crate with equivalents from rmcp (#10349) We started working with MCP in Codex before https://crates.io/crates/rmcp was mature, so we had our own crate for MCP types that was generated from the MCP schema: https://github.com/openai/codex/blob/8b95d3e082376f4cb23e92641705a22afb28a9da/codex-rs/mcp-types/README.md Now that `rmcp` is more mature, it makes more sense to use their MCP types in Rust, as they handle details (like the `_meta` field) that our custom version ignored. Though one advantage that our custom types had is that our generated types implemented `JsonSchema` and `ts_rs::TS`, whereas the types in `rmcp` do not. As such, part of the work of this PR is leveraging the adapters between `rmcp` types and the serializable types that are API for us (app server and MCP) introduced in #10356. Note this PR results in a number of changes to `codex-rs/app-server-protocol/schema`, which merit special attention during review. We must ensure that these changes are still backwards-compatible, which is possible because we have: ```diff - export type CallToolResult = { content: Array<ContentBlock>, isError?: boolean, structuredContent?: JsonValue, }; + export type CallToolResult = { content: Array<JsonValue>, structuredContent?: JsonValue, isError?: boolean, _meta?: JsonValue, }; ``` so `ContentBlock` has been replaced with the more general `JsonValue`. Note that `ContentBlock` was defined as: ```typescript export type ContentBlock = TextContent | ImageContent | AudioContent | ResourceLink | EmbeddedResource; ``` so the deletion of those individual variants should not be a cause of great concern. Similarly, we have the following change in `codex-rs/app-server-protocol/schema/typescript/Tool.ts`: ``` - export type Tool = { annotations?: ToolAnnotations, description?: string, inputSchema: ToolInputSchema, name: string, outputSchema?: ToolOutputSchema, title?: string, }; + export type Tool = { name: string, title?: string, description?: string, inputSchema: JsonValue, outputSchema?: JsonValue, annotations?: JsonValue, icons?: Array<JsonValue>, _meta?: JsonValue, }; ``` so: - `annotations?: ToolAnnotations` ➡️ `JsonValue` - `inputSchema: ToolInputSchema` ➡️ `JsonValue` - `outputSchema?: ToolOutputSchema` ➡️ `JsonValue` and two new fields: `icons?: Array<JsonValue>, _meta?: JsonValue` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10349). * #10357 * __->__ #10349 * #10356
2026-02-02 17:41:55 -08:00
],
"description": "ID of a request, which can be either a string or an integer."
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
},
"RequestUserInputQuestion": {
"properties": {
"header": {
"type": "string"
},
"id": {
"type": "string"
},
"isOther": {
"default": false,
"type": "boolean"
},
"isSecret": {
"default": false,
"type": "boolean"
},
"options": {
"items": {
"$ref": "#/definitions/RequestUserInputQuestionOption"
},
"type": [
"array",
"null"
]
},
"question": {
"type": "string"
}
},
"required": [
"header",
"id",
"question"
],
"type": "object"
},
"RequestUserInputQuestionOption": {
"properties": {
"description": {
"type": "string"
},
"label": {
"type": "string"
}
},
"required": [
"description",
"label"
],
"type": "object"
},
"Resource": {
"description": "A known resource that the server is capable of reading.",
"properties": {
feat: replace custom mcp-types crate with equivalents from rmcp (#10349) We started working with MCP in Codex before https://crates.io/crates/rmcp was mature, so we had our own crate for MCP types that was generated from the MCP schema: https://github.com/openai/codex/blob/8b95d3e082376f4cb23e92641705a22afb28a9da/codex-rs/mcp-types/README.md Now that `rmcp` is more mature, it makes more sense to use their MCP types in Rust, as they handle details (like the `_meta` field) that our custom version ignored. Though one advantage that our custom types had is that our generated types implemented `JsonSchema` and `ts_rs::TS`, whereas the types in `rmcp` do not. As such, part of the work of this PR is leveraging the adapters between `rmcp` types and the serializable types that are API for us (app server and MCP) introduced in #10356. Note this PR results in a number of changes to `codex-rs/app-server-protocol/schema`, which merit special attention during review. We must ensure that these changes are still backwards-compatible, which is possible because we have: ```diff - export type CallToolResult = { content: Array<ContentBlock>, isError?: boolean, structuredContent?: JsonValue, }; + export type CallToolResult = { content: Array<JsonValue>, structuredContent?: JsonValue, isError?: boolean, _meta?: JsonValue, }; ``` so `ContentBlock` has been replaced with the more general `JsonValue`. Note that `ContentBlock` was defined as: ```typescript export type ContentBlock = TextContent | ImageContent | AudioContent | ResourceLink | EmbeddedResource; ``` so the deletion of those individual variants should not be a cause of great concern. Similarly, we have the following change in `codex-rs/app-server-protocol/schema/typescript/Tool.ts`: ``` - export type Tool = { annotations?: ToolAnnotations, description?: string, inputSchema: ToolInputSchema, name: string, outputSchema?: ToolOutputSchema, title?: string, }; + export type Tool = { name: string, title?: string, description?: string, inputSchema: JsonValue, outputSchema?: JsonValue, annotations?: JsonValue, icons?: Array<JsonValue>, _meta?: JsonValue, }; ``` so: - `annotations?: ToolAnnotations` ➡️ `JsonValue` - `inputSchema: ToolInputSchema` ➡️ `JsonValue` - `outputSchema?: ToolOutputSchema` ➡️ `JsonValue` and two new fields: `icons?: Array<JsonValue>, _meta?: JsonValue` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10349). * #10357 * __->__ #10349 * #10356
2026-02-02 17:41:55 -08:00
"_meta": true,
"annotations": true,
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
"description": {
"type": [
"string",
"null"
]
},
feat: replace custom mcp-types crate with equivalents from rmcp (#10349) We started working with MCP in Codex before https://crates.io/crates/rmcp was mature, so we had our own crate for MCP types that was generated from the MCP schema: https://github.com/openai/codex/blob/8b95d3e082376f4cb23e92641705a22afb28a9da/codex-rs/mcp-types/README.md Now that `rmcp` is more mature, it makes more sense to use their MCP types in Rust, as they handle details (like the `_meta` field) that our custom version ignored. Though one advantage that our custom types had is that our generated types implemented `JsonSchema` and `ts_rs::TS`, whereas the types in `rmcp` do not. As such, part of the work of this PR is leveraging the adapters between `rmcp` types and the serializable types that are API for us (app server and MCP) introduced in #10356. Note this PR results in a number of changes to `codex-rs/app-server-protocol/schema`, which merit special attention during review. We must ensure that these changes are still backwards-compatible, which is possible because we have: ```diff - export type CallToolResult = { content: Array<ContentBlock>, isError?: boolean, structuredContent?: JsonValue, }; + export type CallToolResult = { content: Array<JsonValue>, structuredContent?: JsonValue, isError?: boolean, _meta?: JsonValue, }; ``` so `ContentBlock` has been replaced with the more general `JsonValue`. Note that `ContentBlock` was defined as: ```typescript export type ContentBlock = TextContent | ImageContent | AudioContent | ResourceLink | EmbeddedResource; ``` so the deletion of those individual variants should not be a cause of great concern. Similarly, we have the following change in `codex-rs/app-server-protocol/schema/typescript/Tool.ts`: ``` - export type Tool = { annotations?: ToolAnnotations, description?: string, inputSchema: ToolInputSchema, name: string, outputSchema?: ToolOutputSchema, title?: string, }; + export type Tool = { name: string, title?: string, description?: string, inputSchema: JsonValue, outputSchema?: JsonValue, annotations?: JsonValue, icons?: Array<JsonValue>, _meta?: JsonValue, }; ``` so: - `annotations?: ToolAnnotations` ➡️ `JsonValue` - `inputSchema: ToolInputSchema` ➡️ `JsonValue` - `outputSchema?: ToolOutputSchema` ➡️ `JsonValue` and two new fields: `icons?: Array<JsonValue>, _meta?: JsonValue` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10349). * #10357 * __->__ #10349 * #10356
2026-02-02 17:41:55 -08:00
"icons": {
"items": true,
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
"type": [
feat: replace custom mcp-types crate with equivalents from rmcp (#10349) We started working with MCP in Codex before https://crates.io/crates/rmcp was mature, so we had our own crate for MCP types that was generated from the MCP schema: https://github.com/openai/codex/blob/8b95d3e082376f4cb23e92641705a22afb28a9da/codex-rs/mcp-types/README.md Now that `rmcp` is more mature, it makes more sense to use their MCP types in Rust, as they handle details (like the `_meta` field) that our custom version ignored. Though one advantage that our custom types had is that our generated types implemented `JsonSchema` and `ts_rs::TS`, whereas the types in `rmcp` do not. As such, part of the work of this PR is leveraging the adapters between `rmcp` types and the serializable types that are API for us (app server and MCP) introduced in #10356. Note this PR results in a number of changes to `codex-rs/app-server-protocol/schema`, which merit special attention during review. We must ensure that these changes are still backwards-compatible, which is possible because we have: ```diff - export type CallToolResult = { content: Array<ContentBlock>, isError?: boolean, structuredContent?: JsonValue, }; + export type CallToolResult = { content: Array<JsonValue>, structuredContent?: JsonValue, isError?: boolean, _meta?: JsonValue, }; ``` so `ContentBlock` has been replaced with the more general `JsonValue`. Note that `ContentBlock` was defined as: ```typescript export type ContentBlock = TextContent | ImageContent | AudioContent | ResourceLink | EmbeddedResource; ``` so the deletion of those individual variants should not be a cause of great concern. Similarly, we have the following change in `codex-rs/app-server-protocol/schema/typescript/Tool.ts`: ``` - export type Tool = { annotations?: ToolAnnotations, description?: string, inputSchema: ToolInputSchema, name: string, outputSchema?: ToolOutputSchema, title?: string, }; + export type Tool = { name: string, title?: string, description?: string, inputSchema: JsonValue, outputSchema?: JsonValue, annotations?: JsonValue, icons?: Array<JsonValue>, _meta?: JsonValue, }; ``` so: - `annotations?: ToolAnnotations` ➡️ `JsonValue` - `inputSchema: ToolInputSchema` ➡️ `JsonValue` - `outputSchema?: ToolOutputSchema` ➡️ `JsonValue` and two new fields: `icons?: Array<JsonValue>, _meta?: JsonValue` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10349). * #10357 * __->__ #10349 * #10356
2026-02-02 17:41:55 -08:00
"array",
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
"null"
]
},
"mimeType": {
"type": [
"string",
"null"
]
},
"name": {
"type": "string"
},
"size": {
"format": "int64",
"type": [
"integer",
"null"
]
},
"title": {
"type": [
"string",
"null"
]
},
"uri": {
"type": "string"
}
},
"required": [
"name",
"uri"
],
"type": "object"
},
"ResourceTemplate": {
"description": "A template description for resources available on the server.",
"properties": {
feat: replace custom mcp-types crate with equivalents from rmcp (#10349) We started working with MCP in Codex before https://crates.io/crates/rmcp was mature, so we had our own crate for MCP types that was generated from the MCP schema: https://github.com/openai/codex/blob/8b95d3e082376f4cb23e92641705a22afb28a9da/codex-rs/mcp-types/README.md Now that `rmcp` is more mature, it makes more sense to use their MCP types in Rust, as they handle details (like the `_meta` field) that our custom version ignored. Though one advantage that our custom types had is that our generated types implemented `JsonSchema` and `ts_rs::TS`, whereas the types in `rmcp` do not. As such, part of the work of this PR is leveraging the adapters between `rmcp` types and the serializable types that are API for us (app server and MCP) introduced in #10356. Note this PR results in a number of changes to `codex-rs/app-server-protocol/schema`, which merit special attention during review. We must ensure that these changes are still backwards-compatible, which is possible because we have: ```diff - export type CallToolResult = { content: Array<ContentBlock>, isError?: boolean, structuredContent?: JsonValue, }; + export type CallToolResult = { content: Array<JsonValue>, structuredContent?: JsonValue, isError?: boolean, _meta?: JsonValue, }; ``` so `ContentBlock` has been replaced with the more general `JsonValue`. Note that `ContentBlock` was defined as: ```typescript export type ContentBlock = TextContent | ImageContent | AudioContent | ResourceLink | EmbeddedResource; ``` so the deletion of those individual variants should not be a cause of great concern. Similarly, we have the following change in `codex-rs/app-server-protocol/schema/typescript/Tool.ts`: ``` - export type Tool = { annotations?: ToolAnnotations, description?: string, inputSchema: ToolInputSchema, name: string, outputSchema?: ToolOutputSchema, title?: string, }; + export type Tool = { name: string, title?: string, description?: string, inputSchema: JsonValue, outputSchema?: JsonValue, annotations?: JsonValue, icons?: Array<JsonValue>, _meta?: JsonValue, }; ``` so: - `annotations?: ToolAnnotations` ➡️ `JsonValue` - `inputSchema: ToolInputSchema` ➡️ `JsonValue` - `outputSchema?: ToolOutputSchema` ➡️ `JsonValue` and two new fields: `icons?: Array<JsonValue>, _meta?: JsonValue` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10349). * #10357 * __->__ #10349 * #10356
2026-02-02 17:41:55 -08:00
"annotations": true,
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
"description": {
"type": [
"string",
"null"
]
},
"mimeType": {
"type": [
"string",
"null"
]
},
"name": {
"type": "string"
},
"title": {
"type": [
"string",
"null"
]
},
"uriTemplate": {
"type": "string"
}
},
"required": [
"name",
"uriTemplate"
],
"type": "object"
},
"ResponseItem": {
"oneOf": [
{
"properties": {
"content": {
"items": {
"$ref": "#/definitions/ContentItem"
},
"type": "array"
},
"end_turn": {
"type": [
"boolean",
"null"
]
},
"id": {
"type": [
"string",
"null"
],
"writeOnly": true
},
chore: add phase to message responseitem (#10455) ### What add wiring for `phase` field on `ResponseItem::Message` to lay groundwork for differentiating model preambles and final messages. currently optional. follows pattern in #9698. updated schemas with `just write-app-server-schema` so we can see type changes. ### Tests Updated existing tests for SSE parsing and hydrating from history
2026-02-02 18:52:26 -08:00
"phase": {
"anyOf": [
{
"$ref": "#/definitions/MessagePhase"
},
{
"type": "null"
}
]
},
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
"role": {
"type": "string"
},
"type": {
"enum": [
"message"
],
"title": "MessageResponseItemType",
"type": "string"
}
},
"required": [
"content",
"role",
"type"
],
"title": "MessageResponseItem",
"type": "object"
},
{
"properties": {
"content": {
"default": null,
"items": {
"$ref": "#/definitions/ReasoningItemContent"
},
"type": [
"array",
"null"
]
},
"encrypted_content": {
"type": [
"string",
"null"
]
},
"id": {
"type": "string",
"writeOnly": true
},
"summary": {
"items": {
"$ref": "#/definitions/ReasoningItemReasoningSummary"
},
"type": "array"
},
"type": {
"enum": [
"reasoning"
],
"title": "ReasoningResponseItemType",
"type": "string"
}
},
"required": [
"id",
"summary",
"type"
],
"title": "ReasoningResponseItem",
"type": "object"
},
{
"properties": {
"action": {
"$ref": "#/definitions/LocalShellAction"
},
"call_id": {
"description": "Set when using the Responses API.",
"type": [
"string",
"null"
]
},
"id": {
chore: nuke chat/completions API (#10157)
2026-02-03 11:31:57 +00:00
"description": "Legacy id field retained for compatibility with older payloads.",
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
"type": [
"string",
"null"
],
"writeOnly": true
},
"status": {
"$ref": "#/definitions/LocalShellStatus"
},
"type": {
"enum": [
"local_shell_call"
],
"title": "LocalShellCallResponseItemType",
"type": "string"
}
},
"required": [
"action",
"status",
"type"
],
"title": "LocalShellCallResponseItem",
"type": "object"
},
{
"properties": {
"arguments": {
"type": "string"
},
"call_id": {
"type": "string"
},
"id": {
"type": [
"string",
"null"
],
"writeOnly": true
},
"name": {
"type": "string"
},
"type": {
"enum": [
"function_call"
],
"title": "FunctionCallResponseItemType",
"type": "string"
}
},
"required": [
"arguments",
"call_id",
"name",
"type"
],
"title": "FunctionCallResponseItem",
"type": "object"
},
{
"properties": {
"call_id": {
"type": "string"
},
"output": {
"$ref": "#/definitions/FunctionCallOutputPayload"
},
"type": {
"enum": [
"function_call_output"
],
"title": "FunctionCallOutputResponseItemType",
"type": "string"
}
},
"required": [
"call_id",
"output",
"type"
],
"title": "FunctionCallOutputResponseItem",
"type": "object"
},
{
"properties": {
"call_id": {
"type": "string"
},
"id": {
"type": [
"string",
"null"
],
"writeOnly": true
},
"input": {
"type": "string"
},
"name": {
"type": "string"
},
"status": {
"type": [
"string",
"null"
]
},
"type": {
"enum": [
"custom_tool_call"
],
"title": "CustomToolCallResponseItemType",
"type": "string"
}
},
"required": [
"call_id",
"input",
"name",
"type"
],
"title": "CustomToolCallResponseItem",
"type": "object"
},
{
"properties": {
"call_id": {
"type": "string"
},
"output": {
"type": "string"
},
"type": {
"enum": [
"custom_tool_call_output"
],
"title": "CustomToolCallOutputResponseItemType",
"type": "string"
}
},
"required": [
"call_id",
"output",
"type"
],
"title": "CustomToolCallOutputResponseItem",
"type": "object"
},
{
"properties": {
"action": {
"anyOf": [
{
"$ref": "#/definitions/WebSearchAction2"
},
{
"type": "null"
}
]
},
"id": {
"type": [
"string",
"null"
],
"writeOnly": true
},
"status": {
"type": [
"string",
"null"
]
},
"type": {
"enum": [
"web_search_call"
],
"title": "WebSearchCallResponseItemType",
"type": "string"
}
},
"required": [
"type"
],
"title": "WebSearchCallResponseItem",
"type": "object"
},
{
"properties": {
"ghost_commit": {
"$ref": "#/definitions/GhostCommit"
},
"type": {
"enum": [
"ghost_snapshot"
],
"title": "GhostSnapshotResponseItemType",
"type": "string"
}
},
"required": [
"ghost_commit",
"type"
],
"title": "GhostSnapshotResponseItem",
"type": "object"
},
{
"properties": {
"encrypted_content": {
"type": "string"
},
"type": {
"enum": [
"compaction"
],
"title": "CompactionResponseItemType",
"type": "string"
}
},
"required": [
"encrypted_content",
"type"
],
"title": "CompactionResponseItem",
"type": "object"
},
{
"properties": {
"type": {
"enum": [
"other"
],
"title": "OtherResponseItemType",
"type": "string"
}
},
"required": [
"type"
],
"title": "OtherResponseItem",
"type": "object"
}
]
},
"Result_of_CallToolResult_or_String": {
"oneOf": [
{
"properties": {
"Ok": {
"$ref": "#/definitions/CallToolResult"
}
},
"required": [
"Ok"
],
"title": "OkResult_of_CallToolResult_or_String",
"type": "object"
},
{
"properties": {
"Err": {
"type": "string"
}
},
"required": [
"Err"
],
"title": "ErrResult_of_CallToolResult_or_String",
"type": "object"
}
]
},
"ReviewCodeLocation": {
"description": "Location of the code related to a review finding.",
"properties": {
"absolute_file_path": {
"type": "string"
},
"line_range": {
"$ref": "#/definitions/ReviewLineRange"
}
},
"required": [
"absolute_file_path",
"line_range"
],
"type": "object"
},
"ReviewFinding": {
"description": "A single review finding describing an observed issue or recommendation.",
"properties": {
"body": {
"type": "string"
},
"code_location": {
"$ref": "#/definitions/ReviewCodeLocation"
},
"confidence_score": {
"format": "float",
"type": "number"
},
"priority": {
"format": "int32",
"type": "integer"
},
"title": {
"type": "string"
}
},
"required": [
"body",
"code_location",
"confidence_score",
"priority",
"title"
],
"type": "object"
},
"ReviewLineRange": {
"description": "Inclusive line range in a file associated with the finding.",
"properties": {
"end": {
"format": "uint32",
"minimum": 0.0,
"type": "integer"
},
"start": {
"format": "uint32",
"minimum": 0.0,
"type": "integer"
}
},
"required": [
"end",
"start"
],
"type": "object"
},
"ReviewOutputEvent": {
"description": "Structured review result produced by a child review session.",
"properties": {
"findings": {
"items": {
"$ref": "#/definitions/ReviewFinding"
},
"type": "array"
},
"overall_confidence_score": {
"format": "float",
"type": "number"
},
"overall_correctness": {
"type": "string"
},
"overall_explanation": {
"type": "string"
}
},
"required": [
"findings",
"overall_confidence_score",
"overall_correctness",
"overall_explanation"
],
"type": "object"
},
"ReviewTarget": {
"oneOf": [
{
"description": "Review the working tree: staged, unstaged, and untracked files.",
"properties": {
"type": {
"enum": [
"uncommittedChanges"
],
"title": "UncommittedChangesReviewTargetType",
"type": "string"
}
},
"required": [
"type"
],
"title": "UncommittedChangesReviewTarget",
"type": "object"
},
{
"description": "Review changes between the current branch and the given base branch.",
"properties": {
"branch": {
"type": "string"
},
"type": {
"enum": [
"baseBranch"
],
"title": "BaseBranchReviewTargetType",
"type": "string"
}
},
"required": [
"branch",
"type"
],
"title": "BaseBranchReviewTarget",
"type": "object"
},
{
"description": "Review the changes introduced by a specific commit.",
"properties": {
"sha": {
"type": "string"
},
"title": {
"description": "Optional human-readable label (e.g., commit subject) for UIs.",
"type": [
"string",
"null"
]
},
"type": {
"enum": [
"commit"
],
"title": "CommitReviewTargetType",
"type": "string"
}
},
"required": [
"sha",
"type"
],
"title": "CommitReviewTarget",
"type": "object"
},
{
"description": "Arbitrary instructions provided by the user.",
"properties": {
"instructions": {
"type": "string"
},
"type": {
"enum": [
"custom"
],
"title": "CustomReviewTargetType",
"type": "string"
}
},
"required": [
"instructions",
"type"
],
"title": "CustomReviewTarget",
"type": "object"
}
]
},
"SandboxPolicy": {
"description": "Determines execution restrictions for model shell commands.",
"oneOf": [
{
"description": "No restrictions whatsoever. Use with caution.",
"properties": {
"type": {
"enum": [
"danger-full-access"
],
"title": "DangerFullAccessSandboxPolicyType",
"type": "string"
}
},
"required": [
"type"
],
"title": "DangerFullAccessSandboxPolicy",
"type": "object"
},
{
"description": "Read-only access to the entire file-system.",
"properties": {
"type": {
"enum": [
"read-only"
],
"title": "ReadOnlySandboxPolicyType",
"type": "string"
}
},
"required": [
"type"
],
"title": "ReadOnlySandboxPolicy",
"type": "object"
},
{
"description": "Indicates the process is already in an external sandbox. Allows full disk access while honoring the provided network setting.",
"properties": {
"network_access": {
"allOf": [
{
"$ref": "#/definitions/NetworkAccess"
}
],
"default": "restricted",
"description": "Whether the external sandbox permits outbound network traffic."
},
"type": {
"enum": [
"external-sandbox"
],
"title": "ExternalSandboxSandboxPolicyType",
"type": "string"
}
},
"required": [
"type"
],
"title": "ExternalSandboxSandboxPolicy",
"type": "object"
},
{
"description": "Same as `ReadOnly` but additionally grants write access to the current working directory (\"workspace\").",
"properties": {
"exclude_slash_tmp": {
"default": false,
"description": "When set to `true`, will NOT include the `/tmp` among the default writable roots on UNIX. Defaults to `false`.",
"type": "boolean"
},
"exclude_tmpdir_env_var": {
"default": false,
"description": "When set to `true`, will NOT include the per-user `TMPDIR` environment variable among the default writable roots. Defaults to `false`.",
"type": "boolean"
},
"network_access": {
"default": false,
"description": "When set to `true`, outbound network access is allowed. `false` by default.",
"type": "boolean"
},
"type": {
"enum": [
"workspace-write"
],
"title": "WorkspaceWriteSandboxPolicyType",
"type": "string"
},
"writable_roots": {
"description": "Additional folders (beyond cwd and possibly TMPDIR) that should be writable from within the sandbox.",
"items": {
"$ref": "#/definitions/AbsolutePathBuf"
},
"type": "array"
}
},
"required": [
"type"
],
"title": "WorkspaceWriteSandboxPolicy",
"type": "object"
}
]
},
"SessionConfiguredNotification": {
"properties": {
"historyEntryCount": {
"format": "uint",
"minimum": 0.0,
"type": "integer"
},
"historyLogId": {
"format": "uint64",
"minimum": 0.0,
"type": "integer"
},
"initialMessages": {
"items": {
"$ref": "#/definitions/EventMsg"
},
"type": [
"array",
"null"
]
},
"model": {
"type": "string"
},
"reasoningEffort": {
"anyOf": [
{
"$ref": "#/definitions/ReasoningEffort"
},
{
"type": "null"
}
]
},
"rolloutPath": {
"type": "string"
},
"sessionId": {
"$ref": "#/definitions/ThreadId"
}
},
"required": [
"historyEntryCount",
"historyLogId",
"model",
"rolloutPath",
"sessionId"
],
"type": "object"
},
"SessionSource": {
"oneOf": [
{
"enum": [
"cli",
"vscode",
"exec",
"appServer",
"unknown"
],
"type": "string"
},
{
"additionalProperties": false,
"properties": {
"subAgent": {
"$ref": "#/definitions/SubAgentSource"
}
},
"required": [
"subAgent"
],
"title": "SubAgentSessionSource",
"type": "object"
}
]
},
"SkillDependencies": {
"properties": {
"tools": {
"items": {
"$ref": "#/definitions/SkillToolDependency"
},
"type": "array"
}
},
"required": [
"tools"
],
"type": "object"
},
"SkillErrorInfo": {
"properties": {
"message": {
"type": "string"
},
"path": {
"type": "string"
}
},
"required": [
"message",
"path"
],
"type": "object"
},
"SkillInterface": {
"properties": {
"brand_color": {
"type": [
"string",
"null"
]
},
"default_prompt": {
"type": [
"string",
"null"
]
},
"display_name": {
"type": [
"string",
"null"
]
},
"icon_large": {
"type": [
"string",
"null"
]
},
"icon_small": {
"type": [
"string",
"null"
]
},
"short_description": {
"type": [
"string",
"null"
]
}
},
"type": "object"
},
"SkillMetadata": {
"properties": {
"dependencies": {
"anyOf": [
{
"$ref": "#/definitions/SkillDependencies"
},
{
"type": "null"
}
]
},
"description": {
"type": "string"
},
"enabled": {
"type": "boolean"
},
"interface": {
"anyOf": [
{
"$ref": "#/definitions/SkillInterface"
},
{
"type": "null"
}
]
},
"name": {
"type": "string"
},
"path": {
"type": "string"
},
"scope": {
"$ref": "#/definitions/SkillScope"
},
"short_description": {
"description": "Legacy short_description from SKILL.md. Prefer SKILL.json interface.short_description.",
"type": [
"string",
"null"
]
}
},
"required": [
"description",
"enabled",
"name",
"path",
"scope"
],
"type": "object"
},
"SkillScope": {
"enum": [
"user",
"repo",
"system",
"admin"
],
"type": "string"
},
"SkillToolDependency": {
"properties": {
"command": {
"type": [
"string",
"null"
]
},
"description": {
"type": [
"string",
"null"
]
},
"transport": {
"type": [
"string",
"null"
]
},
"type": {
"type": "string"
},
"url": {
"type": [
"string",
"null"
]
},
"value": {
"type": "string"
}
},
"required": [
"type",
"value"
],
"type": "object"
},
"SkillsListEntry": {
"properties": {
"cwd": {
"type": "string"
},
"errors": {
"items": {
"$ref": "#/definitions/SkillErrorInfo"
},
"type": "array"
},
"skills": {
"items": {
"$ref": "#/definitions/SkillMetadata"
},
"type": "array"
}
},
"required": [
"cwd",
"errors",
"skills"
],
"type": "object"
},
"StepStatus": {
"enum": [
"pending",
"in_progress",
"completed"
],
"type": "string"
},
"SubAgentSource": {
"oneOf": [
{
"enum": [
"review",
"compact"
],
"type": "string"
},
{
"additionalProperties": false,
"properties": {
"thread_spawn": {
"properties": {
"depth": {
"format": "int32",
"type": "integer"
},
"parent_thread_id": {
"$ref": "#/definitions/ThreadId"
}
},
"required": [
"depth",
"parent_thread_id"
],
"type": "object"
}
},
"required": [
"thread_spawn"
],
"title": "ThreadSpawnSubAgentSource",
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"other": {
"type": "string"
}
},
"required": [
"other"
],
"title": "OtherSubAgentSource",
"type": "object"
}
]
},
"TerminalInteractionNotification": {
"properties": {
"itemId": {
"type": "string"
},
"processId": {
"type": "string"
},
"stdin": {
"type": "string"
},
"threadId": {
"type": "string"
},
"turnId": {
"type": "string"
}
},
"required": [
"itemId",
"processId",
"stdin",
"threadId",
"turnId"
],
"type": "object"
},
"TextElement": {
"properties": {
"byteRange": {
"allOf": [
{
"$ref": "#/definitions/ByteRange"
}
],
"description": "Byte range in the parent `text` buffer that this element occupies."
},
"placeholder": {
"description": "Optional human-readable placeholder for the element, displayed in the UI.",
"type": [
"string",
"null"
]
}
},
"required": [
"byteRange"
],
"type": "object"
},
"TextElement2": {
"properties": {
"byte_range": {
"allOf": [
{
"$ref": "#/definitions/ByteRange2"
}
],
"description": "Byte range in the parent `text` buffer that this element occupies."
},
"placeholder": {
"description": "Optional human-readable placeholder for the element, displayed in the UI.",
"type": [
"string",
"null"
]
}
},
"required": [
"byte_range"
],
"type": "object"
},
"TextPosition": {
"properties": {
"column": {
"description": "1-based column number (in Unicode scalar values).",
"format": "uint",
"minimum": 0.0,
"type": "integer"
},
"line": {
"description": "1-based line number.",
"format": "uint",
"minimum": 0.0,
"type": "integer"
}
},
"required": [
"column",
"line"
],
"type": "object"
},
"TextRange": {
"properties": {
"end": {
"$ref": "#/definitions/TextPosition"
},
"start": {
"$ref": "#/definitions/TextPosition"
}
},
"required": [
"end",
"start"
],
"type": "object"
},
"Thread": {
"properties": {
"cliVersion": {
"description": "Version of the CLI that created the thread.",
"type": "string"
},
"createdAt": {
"description": "Unix timestamp (in seconds) when the thread was created.",
"format": "int64",
"type": "integer"
},
"cwd": {
"description": "Working directory captured for the thread.",
"type": "string"
},
"gitInfo": {
"anyOf": [
{
"$ref": "#/definitions/GitInfo"
},
{
"type": "null"
}
],
"description": "Optional Git metadata captured when the thread was created."
},
"id": {
"type": "string"
},
"modelProvider": {
"description": "Model provider used for this thread (for example, 'openai').",
"type": "string"
},
"path": {
"description": "[UNSTABLE] Path to the thread on disk.",
"type": [
"string",
"null"
]
},
"preview": {
"description": "Usually the first user message in the thread, if available.",
"type": "string"
},
"source": {
"allOf": [
{
"$ref": "#/definitions/SessionSource"
}
],
"description": "Origin of the thread (CLI, VSCode, codex exec, codex app-server, etc.)."
},
"turns": {
"description": "Only populated on `thread/resume`, `thread/rollback`, `thread/fork`, and `thread/read` (when `includeTurns` is true) responses. For all other responses and notifications returning a Thread, the turns field will be an empty list.",
"items": {
"$ref": "#/definitions/Turn"
},
"type": "array"
},
"updatedAt": {
"description": "Unix timestamp (in seconds) when the thread was last updated.",
"format": "int64",
"type": "integer"
}
},
"required": [
"cliVersion",
"createdAt",
"cwd",
"id",
"modelProvider",
"preview",
"source",
"turns",
"updatedAt"
],
"type": "object"
},
"ThreadId": {
"type": "string"
},
"ThreadItem": {
"oneOf": [
{
"properties": {
"content": {
"items": {
"$ref": "#/definitions/UserInput"
},
"type": "array"
},
"id": {
"type": "string"
},
"type": {
"enum": [
"userMessage"
],
"title": "UserMessageThreadItemType",
"type": "string"
}
},
"required": [
"content",
"id",
"type"
],
"title": "UserMessageThreadItem",
"type": "object"
},
{
"properties": {
"id": {
"type": "string"
},
"text": {
"type": "string"
},
"type": {
"enum": [
"agentMessage"
],
"title": "AgentMessageThreadItemType",
"type": "string"
}
},
"required": [
"id",
"text",
"type"
],
"title": "AgentMessageThreadItem",
"type": "object"
},
{
"description": "EXPERIMENTAL - proposed plan item content. The completed plan item is authoritative and may not match the concatenation of `PlanDelta` text.",
"properties": {
"id": {
"type": "string"
},
"text": {
"type": "string"
},
"type": {
"enum": [
"plan"
],
"title": "PlanThreadItemType",
"type": "string"
}
},
"required": [
"id",
"text",
"type"
],
"title": "PlanThreadItem",
"type": "object"
},
{
"properties": {
"content": {
"default": [],
"items": {
"type": "string"
},
"type": "array"
},
"id": {
"type": "string"
},
"summary": {
"default": [],
"items": {
"type": "string"
},
"type": "array"
},
"type": {
"enum": [
"reasoning"
],
"title": "ReasoningThreadItemType",
"type": "string"
}
},
"required": [
"id",
"type"
],
"title": "ReasoningThreadItem",
"type": "object"
},
{
"properties": {
"aggregatedOutput": {
"description": "The command's output, aggregated from stdout and stderr.",
"type": [
"string",
"null"
]
},
"command": {
"description": "The command to be executed.",
"type": "string"
},
"commandActions": {
"description": "A best-effort parsing of the command to understand the action(s) it will perform. This returns a list of CommandAction objects because a single shell command may be composed of many commands piped together.",
"items": {
"$ref": "#/definitions/CommandAction"
},
"type": "array"
},
"cwd": {
"description": "The command's working directory.",
"type": "string"
},
"durationMs": {
"description": "The duration of the command execution in milliseconds.",
"format": "int64",
"type": [
"integer",
"null"
]
},
"exitCode": {
"description": "The command's exit code.",
"format": "int32",
"type": [
"integer",
"null"
]
},
"id": {
"type": "string"
},
"processId": {
"description": "Identifier for the underlying PTY process (when available).",
"type": [
"string",
"null"
]
},
"status": {
"$ref": "#/definitions/CommandExecutionStatus"
},
"type": {
"enum": [
"commandExecution"
],
"title": "CommandExecutionThreadItemType",
"type": "string"
}
},
"required": [
"command",
"commandActions",
"cwd",
"id",
"status",
"type"
],
"title": "CommandExecutionThreadItem",
"type": "object"
},
{
"properties": {
"changes": {
"items": {
"$ref": "#/definitions/FileUpdateChange"
},
"type": "array"
},
"id": {
"type": "string"
},
"status": {
"$ref": "#/definitions/PatchApplyStatus"
},
"type": {
"enum": [
"fileChange"
],
"title": "FileChangeThreadItemType",
"type": "string"
}
},
"required": [
"changes",
"id",
"status",
"type"
],
"title": "FileChangeThreadItem",
"type": "object"
},
{
"properties": {
"arguments": true,
"durationMs": {
"description": "The duration of the MCP tool call in milliseconds.",
"format": "int64",
"type": [
"integer",
"null"
]
},
"error": {
"anyOf": [
{
"$ref": "#/definitions/McpToolCallError"
},
{
"type": "null"
}
]
},
"id": {
"type": "string"
},
"result": {
"anyOf": [
{
"$ref": "#/definitions/McpToolCallResult"
},
{
"type": "null"
}
]
},
"server": {
"type": "string"
},
"status": {
"$ref": "#/definitions/McpToolCallStatus"
},
"tool": {
"type": "string"
},
"type": {
"enum": [
"mcpToolCall"
],
"title": "McpToolCallThreadItemType",
"type": "string"
}
},
"required": [
"arguments",
"id",
"server",
"status",
"tool",
"type"
],
"title": "McpToolCallThreadItem",
"type": "object"
},
{
"properties": {
"agentsStates": {
"additionalProperties": {
"$ref": "#/definitions/CollabAgentState"
},
"description": "Last known status of the target agents, when available.",
"type": "object"
},
"id": {
"description": "Unique identifier for this collab tool call.",
"type": "string"
},
"prompt": {
"description": "Prompt text sent as part of the collab tool call, when available.",
"type": [
"string",
"null"
]
},
"receiverThreadIds": {
"description": "Thread ID of the receiving agent, when applicable. In case of spawn operation, this corresponds to the newly spawned agent.",
"items": {
"type": "string"
},
"type": "array"
},
"senderThreadId": {
"description": "Thread ID of the agent issuing the collab request.",
"type": "string"
},
"status": {
"allOf": [
{
"$ref": "#/definitions/CollabAgentToolCallStatus"
}
],
"description": "Current status of the collab tool call."
},
"tool": {
"allOf": [
{
"$ref": "#/definitions/CollabAgentTool"
}
],
"description": "Name of the collab tool that was invoked."
},
"type": {
"enum": [
"collabAgentToolCall"
],
"title": "CollabAgentToolCallThreadItemType",
"type": "string"
}
},
"required": [
"agentsStates",
"id",
"receiverThreadIds",
"senderThreadId",
"status",
"tool",
"type"
],
"title": "CollabAgentToolCallThreadItem",
"type": "object"
},
{
"properties": {
"action": {
"anyOf": [
{
"$ref": "#/definitions/WebSearchAction"
},
{
"type": "null"
}
]
},
"id": {
"type": "string"
},
"query": {
"type": "string"
},
"type": {
"enum": [
"webSearch"
],
"title": "WebSearchThreadItemType",
"type": "string"
}
},
"required": [
"id",
"query",
"type"
],
"title": "WebSearchThreadItem",
"type": "object"
},
{
"properties": {
"id": {
"type": "string"
},
"path": {
"type": "string"
},
"type": {
"enum": [
"imageView"
],
"title": "ImageViewThreadItemType",
"type": "string"
}
},
"required": [
"id",
"path",
"type"
],
"title": "ImageViewThreadItem",
"type": "object"
},
{
"properties": {
"id": {
"type": "string"
},
"review": {
"type": "string"
},
"type": {
"enum": [
"enteredReviewMode"
],
"title": "EnteredReviewModeThreadItemType",
"type": "string"
}
},
"required": [
"id",
"review",
"type"
],
"title": "EnteredReviewModeThreadItem",
"type": "object"
},
{
"properties": {
"id": {
"type": "string"
},
"review": {
"type": "string"
},
"type": {
"enum": [
"exitedReviewMode"
],
"title": "ExitedReviewModeThreadItemType",
"type": "string"
}
},
"required": [
"id",
"review",
"type"
],
"title": "ExitedReviewModeThreadItem",
"type": "object"
},
{
"properties": {
"id": {
"type": "string"
},
"type": {
"enum": [
"contextCompaction"
],
"title": "ContextCompactionThreadItemType",
"type": "string"
}
},
"required": [
"id",
"type"
],
"title": "ContextCompactionThreadItem",
"type": "object"
}
]
},
"ThreadNameUpdatedNotification": {
"properties": {
"threadId": {
"type": "string"
},
"threadName": {
"type": [
"string",
"null"
]
}
},
"required": [
"threadId"
],
"type": "object"
},
"ThreadStartedNotification": {
"properties": {
"thread": {
"$ref": "#/definitions/Thread"
}
},
"required": [
"thread"
],
"type": "object"
},
"ThreadTokenUsage": {
"properties": {
"last": {
"$ref": "#/definitions/TokenUsageBreakdown"
},
"modelContextWindow": {
"format": "int64",
"type": [
"integer",
"null"
]
},
"total": {
"$ref": "#/definitions/TokenUsageBreakdown"
}
},
"required": [
"last",
"total"
],
"type": "object"
},
"ThreadTokenUsageUpdatedNotification": {
"properties": {
"threadId": {
"type": "string"
},
"tokenUsage": {
"$ref": "#/definitions/ThreadTokenUsage"
},
"turnId": {
"type": "string"
}
},
"required": [
"threadId",
"tokenUsage",
"turnId"
],
"type": "object"
},
"TokenUsage": {
"properties": {
"cached_input_tokens": {
"format": "int64",
"type": "integer"
},
"input_tokens": {
"format": "int64",
"type": "integer"
},
"output_tokens": {
"format": "int64",
"type": "integer"
},
"reasoning_output_tokens": {
"format": "int64",
"type": "integer"
},
"total_tokens": {
"format": "int64",
"type": "integer"
}
},
"required": [
"cached_input_tokens",
"input_tokens",
"output_tokens",
"reasoning_output_tokens",
"total_tokens"
],
"type": "object"
},
"TokenUsageBreakdown": {
"properties": {
"cachedInputTokens": {
"format": "int64",
"type": "integer"
},
"inputTokens": {
"format": "int64",
"type": "integer"
},
"outputTokens": {
"format": "int64",
"type": "integer"
},
"reasoningOutputTokens": {
"format": "int64",
"type": "integer"
},
"totalTokens": {
"format": "int64",
"type": "integer"
}
},
"required": [
"cachedInputTokens",
"inputTokens",
"outputTokens",
"reasoningOutputTokens",
"totalTokens"
],
"type": "object"
},
"TokenUsageInfo": {
"properties": {
"last_token_usage": {
"$ref": "#/definitions/TokenUsage"
},
"model_context_window": {
"format": "int64",
"type": [
"integer",
"null"
]
},
"total_token_usage": {
"$ref": "#/definitions/TokenUsage"
}
},
"required": [
"last_token_usage",
"total_token_usage"
],
"type": "object"
},
"Tool": {
"description": "Definition for a tool the client can call.",
"properties": {
feat: replace custom mcp-types crate with equivalents from rmcp (#10349) We started working with MCP in Codex before https://crates.io/crates/rmcp was mature, so we had our own crate for MCP types that was generated from the MCP schema: https://github.com/openai/codex/blob/8b95d3e082376f4cb23e92641705a22afb28a9da/codex-rs/mcp-types/README.md Now that `rmcp` is more mature, it makes more sense to use their MCP types in Rust, as they handle details (like the `_meta` field) that our custom version ignored. Though one advantage that our custom types had is that our generated types implemented `JsonSchema` and `ts_rs::TS`, whereas the types in `rmcp` do not. As such, part of the work of this PR is leveraging the adapters between `rmcp` types and the serializable types that are API for us (app server and MCP) introduced in #10356. Note this PR results in a number of changes to `codex-rs/app-server-protocol/schema`, which merit special attention during review. We must ensure that these changes are still backwards-compatible, which is possible because we have: ```diff - export type CallToolResult = { content: Array<ContentBlock>, isError?: boolean, structuredContent?: JsonValue, }; + export type CallToolResult = { content: Array<JsonValue>, structuredContent?: JsonValue, isError?: boolean, _meta?: JsonValue, }; ``` so `ContentBlock` has been replaced with the more general `JsonValue`. Note that `ContentBlock` was defined as: ```typescript export type ContentBlock = TextContent | ImageContent | AudioContent | ResourceLink | EmbeddedResource; ``` so the deletion of those individual variants should not be a cause of great concern. Similarly, we have the following change in `codex-rs/app-server-protocol/schema/typescript/Tool.ts`: ``` - export type Tool = { annotations?: ToolAnnotations, description?: string, inputSchema: ToolInputSchema, name: string, outputSchema?: ToolOutputSchema, title?: string, }; + export type Tool = { name: string, title?: string, description?: string, inputSchema: JsonValue, outputSchema?: JsonValue, annotations?: JsonValue, icons?: Array<JsonValue>, _meta?: JsonValue, }; ``` so: - `annotations?: ToolAnnotations` ➡️ `JsonValue` - `inputSchema: ToolInputSchema` ➡️ `JsonValue` - `outputSchema?: ToolOutputSchema` ➡️ `JsonValue` and two new fields: `icons?: Array<JsonValue>, _meta?: JsonValue` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10349). * #10357 * __->__ #10349 * #10356
2026-02-02 17:41:55 -08:00
"_meta": true,
"annotations": true,
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
"description": {
"type": [
"string",
"null"
]
},
feat: replace custom mcp-types crate with equivalents from rmcp (#10349) We started working with MCP in Codex before https://crates.io/crates/rmcp was mature, so we had our own crate for MCP types that was generated from the MCP schema: https://github.com/openai/codex/blob/8b95d3e082376f4cb23e92641705a22afb28a9da/codex-rs/mcp-types/README.md Now that `rmcp` is more mature, it makes more sense to use their MCP types in Rust, as they handle details (like the `_meta` field) that our custom version ignored. Though one advantage that our custom types had is that our generated types implemented `JsonSchema` and `ts_rs::TS`, whereas the types in `rmcp` do not. As such, part of the work of this PR is leveraging the adapters between `rmcp` types and the serializable types that are API for us (app server and MCP) introduced in #10356. Note this PR results in a number of changes to `codex-rs/app-server-protocol/schema`, which merit special attention during review. We must ensure that these changes are still backwards-compatible, which is possible because we have: ```diff - export type CallToolResult = { content: Array<ContentBlock>, isError?: boolean, structuredContent?: JsonValue, }; + export type CallToolResult = { content: Array<JsonValue>, structuredContent?: JsonValue, isError?: boolean, _meta?: JsonValue, }; ``` so `ContentBlock` has been replaced with the more general `JsonValue`. Note that `ContentBlock` was defined as: ```typescript export type ContentBlock = TextContent | ImageContent | AudioContent | ResourceLink | EmbeddedResource; ``` so the deletion of those individual variants should not be a cause of great concern. Similarly, we have the following change in `codex-rs/app-server-protocol/schema/typescript/Tool.ts`: ``` - export type Tool = { annotations?: ToolAnnotations, description?: string, inputSchema: ToolInputSchema, name: string, outputSchema?: ToolOutputSchema, title?: string, }; + export type Tool = { name: string, title?: string, description?: string, inputSchema: JsonValue, outputSchema?: JsonValue, annotations?: JsonValue, icons?: Array<JsonValue>, _meta?: JsonValue, }; ``` so: - `annotations?: ToolAnnotations` ➡️ `JsonValue` - `inputSchema: ToolInputSchema` ➡️ `JsonValue` - `outputSchema?: ToolOutputSchema` ➡️ `JsonValue` and two new fields: `icons?: Array<JsonValue>, _meta?: JsonValue` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10349). * #10357 * __->__ #10349 * #10356
2026-02-02 17:41:55 -08:00
"icons": {
"items": true,
"type": [
"array",
"null"
]
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
},
feat: replace custom mcp-types crate with equivalents from rmcp (#10349) We started working with MCP in Codex before https://crates.io/crates/rmcp was mature, so we had our own crate for MCP types that was generated from the MCP schema: https://github.com/openai/codex/blob/8b95d3e082376f4cb23e92641705a22afb28a9da/codex-rs/mcp-types/README.md Now that `rmcp` is more mature, it makes more sense to use their MCP types in Rust, as they handle details (like the `_meta` field) that our custom version ignored. Though one advantage that our custom types had is that our generated types implemented `JsonSchema` and `ts_rs::TS`, whereas the types in `rmcp` do not. As such, part of the work of this PR is leveraging the adapters between `rmcp` types and the serializable types that are API for us (app server and MCP) introduced in #10356. Note this PR results in a number of changes to `codex-rs/app-server-protocol/schema`, which merit special attention during review. We must ensure that these changes are still backwards-compatible, which is possible because we have: ```diff - export type CallToolResult = { content: Array<ContentBlock>, isError?: boolean, structuredContent?: JsonValue, }; + export type CallToolResult = { content: Array<JsonValue>, structuredContent?: JsonValue, isError?: boolean, _meta?: JsonValue, }; ``` so `ContentBlock` has been replaced with the more general `JsonValue`. Note that `ContentBlock` was defined as: ```typescript export type ContentBlock = TextContent | ImageContent | AudioContent | ResourceLink | EmbeddedResource; ``` so the deletion of those individual variants should not be a cause of great concern. Similarly, we have the following change in `codex-rs/app-server-protocol/schema/typescript/Tool.ts`: ``` - export type Tool = { annotations?: ToolAnnotations, description?: string, inputSchema: ToolInputSchema, name: string, outputSchema?: ToolOutputSchema, title?: string, }; + export type Tool = { name: string, title?: string, description?: string, inputSchema: JsonValue, outputSchema?: JsonValue, annotations?: JsonValue, icons?: Array<JsonValue>, _meta?: JsonValue, }; ``` so: - `annotations?: ToolAnnotations` ➡️ `JsonValue` - `inputSchema: ToolInputSchema` ➡️ `JsonValue` - `outputSchema?: ToolOutputSchema` ➡️ `JsonValue` and two new fields: `icons?: Array<JsonValue>, _meta?: JsonValue` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10349). * #10357 * __->__ #10349 * #10356
2026-02-02 17:41:55 -08:00
"inputSchema": true,
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
"name": {
"type": "string"
},
feat: replace custom mcp-types crate with equivalents from rmcp (#10349) We started working with MCP in Codex before https://crates.io/crates/rmcp was mature, so we had our own crate for MCP types that was generated from the MCP schema: https://github.com/openai/codex/blob/8b95d3e082376f4cb23e92641705a22afb28a9da/codex-rs/mcp-types/README.md Now that `rmcp` is more mature, it makes more sense to use their MCP types in Rust, as they handle details (like the `_meta` field) that our custom version ignored. Though one advantage that our custom types had is that our generated types implemented `JsonSchema` and `ts_rs::TS`, whereas the types in `rmcp` do not. As such, part of the work of this PR is leveraging the adapters between `rmcp` types and the serializable types that are API for us (app server and MCP) introduced in #10356. Note this PR results in a number of changes to `codex-rs/app-server-protocol/schema`, which merit special attention during review. We must ensure that these changes are still backwards-compatible, which is possible because we have: ```diff - export type CallToolResult = { content: Array<ContentBlock>, isError?: boolean, structuredContent?: JsonValue, }; + export type CallToolResult = { content: Array<JsonValue>, structuredContent?: JsonValue, isError?: boolean, _meta?: JsonValue, }; ``` so `ContentBlock` has been replaced with the more general `JsonValue`. Note that `ContentBlock` was defined as: ```typescript export type ContentBlock = TextContent | ImageContent | AudioContent | ResourceLink | EmbeddedResource; ``` so the deletion of those individual variants should not be a cause of great concern. Similarly, we have the following change in `codex-rs/app-server-protocol/schema/typescript/Tool.ts`: ``` - export type Tool = { annotations?: ToolAnnotations, description?: string, inputSchema: ToolInputSchema, name: string, outputSchema?: ToolOutputSchema, title?: string, }; + export type Tool = { name: string, title?: string, description?: string, inputSchema: JsonValue, outputSchema?: JsonValue, annotations?: JsonValue, icons?: Array<JsonValue>, _meta?: JsonValue, }; ``` so: - `annotations?: ToolAnnotations` ➡️ `JsonValue` - `inputSchema: ToolInputSchema` ➡️ `JsonValue` - `outputSchema?: ToolOutputSchema` ➡️ `JsonValue` and two new fields: `icons?: Array<JsonValue>, _meta?: JsonValue` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10349). * #10357 * __->__ #10349 * #10356
2026-02-02 17:41:55 -08:00
"outputSchema": true,
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
"title": {
"type": [
"string",
"null"
]
}
},
"required": [
"inputSchema",
"name"
],
"type": "object"
},
"Turn": {
"properties": {
"error": {
"anyOf": [
{
"$ref": "#/definitions/TurnError"
},
{
"type": "null"
}
],
"description": "Only populated when the Turn's status is failed."
},
"id": {
"type": "string"
},
"items": {
"description": "Only populated on a `thread/resume` or `thread/fork` response. For all other responses and notifications returning a Turn, the items field will be an empty list.",
"items": {
"$ref": "#/definitions/ThreadItem"
},
"type": "array"
},
"status": {
"$ref": "#/definitions/TurnStatus"
}
},
"required": [
"id",
"items",
"status"
],
"type": "object"
},
"TurnAbortReason": {
"enum": [
"interrupted",
"replaced",
"review_ended"
],
"type": "string"
},
"TurnCompletedNotification": {
"properties": {
"threadId": {
"type": "string"
},
"turn": {
"$ref": "#/definitions/Turn"
}
},
"required": [
"threadId",
"turn"
],
"type": "object"
},
"TurnDiffUpdatedNotification": {
"description": "Notification that the turn-level unified diff has changed. Contains the latest aggregated diff across all file changes in the turn.",
"properties": {
"diff": {
"type": "string"
},
"threadId": {
"type": "string"
},
"turnId": {
"type": "string"
}
},
"required": [
"diff",
"threadId",
"turnId"
],
"type": "object"
},
"TurnError": {
"properties": {
"additionalDetails": {
"default": null,
"type": [
"string",
"null"
]
},
"codexErrorInfo": {
"anyOf": [
{
"$ref": "#/definitions/CodexErrorInfo"
},
{
"type": "null"
}
]
},
"message": {
"type": "string"
}
},
"required": [
"message"
],
"type": "object"
},
"TurnItem": {
"oneOf": [
{
"properties": {
"content": {
"items": {
"$ref": "#/definitions/UserInput2"
},
"type": "array"
},
"id": {
"type": "string"
},
"type": {
"enum": [
"UserMessage"
],
"title": "UserMessageTurnItemType",
"type": "string"
}
},
"required": [
"content",
"id",
"type"
],
"title": "UserMessageTurnItem",
"type": "object"
},
{
fix(tui): conditionally restore status indicator using message phase (#10947) TLDR: use new message phase field emitted by preamble-supported models to determine whether an AgentMessage is mid-turn commentary. if so, restore the status indicator afterwards to indicate the turn has not completed. ### Problem `commit_tick` hides the status indicator while streaming assistant text. For preamble-capable models, that text can be commentary mid-turn, so hiding was correct during streaming but restore timing mattered: - restoring too aggressively caused jitter/flashing - not restoring caused indicator to stay hidden before subsequent work (tool calls, web search, etc.) ### Fix - Add optional `phase` to `AgentMessageItem` and propagate it from `ResponseItem::Message` - Keep indicator hidden during streamed commit ticks, restore only when: - assistant item completes as `phase=commentary`, and - stream queues are idle + task is still running. - Treat `phase=None` as final-answer behavior (no restore) to keep existing behavior for non-preamble models ### Tests Add/update tests for: - no idle-tick restore without commentary completion - commentary completion restoring status before tool begin - snapshot coverage for preamble/status behavior --------- Co-authored-by: Josh McKinney <joshka@openai.com>
2026-02-06 18:39:52 -08:00
"description": "Assistant-authored message payload used in turn-item streams.\n\n`phase` is optional because not all providers/models emit it. Consumers should use it when present, but retain legacy completion semantics when it is `None`.",
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
"properties": {
"content": {
"items": {
"$ref": "#/definitions/AgentMessageContent"
},
"type": "array"
},
"id": {
"type": "string"
},
fix(tui): conditionally restore status indicator using message phase (#10947) TLDR: use new message phase field emitted by preamble-supported models to determine whether an AgentMessage is mid-turn commentary. if so, restore the status indicator afterwards to indicate the turn has not completed. ### Problem `commit_tick` hides the status indicator while streaming assistant text. For preamble-capable models, that text can be commentary mid-turn, so hiding was correct during streaming but restore timing mattered: - restoring too aggressively caused jitter/flashing - not restoring caused indicator to stay hidden before subsequent work (tool calls, web search, etc.) ### Fix - Add optional `phase` to `AgentMessageItem` and propagate it from `ResponseItem::Message` - Keep indicator hidden during streamed commit ticks, restore only when: - assistant item completes as `phase=commentary`, and - stream queues are idle + task is still running. - Treat `phase=None` as final-answer behavior (no restore) to keep existing behavior for non-preamble models ### Tests Add/update tests for: - no idle-tick restore without commentary completion - commentary completion restoring status before tool begin - snapshot coverage for preamble/status behavior --------- Co-authored-by: Josh McKinney <joshka@openai.com>
2026-02-06 18:39:52 -08:00
"phase": {
"anyOf": [
{
"$ref": "#/definitions/MessagePhase"
},
{
"type": "null"
}
],
"description": "Optional phase metadata carried through from `ResponseItem::Message`.\n\nThis is currently used by TUI rendering to distinguish mid-turn commentary from a final answer and avoid status-indicator jitter."
},
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
"type": {
"enum": [
"AgentMessage"
],
"title": "AgentMessageTurnItemType",
"type": "string"
}
},
"required": [
"content",
"id",
"type"
],
"title": "AgentMessageTurnItem",
"type": "object"
},
{
"properties": {
"id": {
"type": "string"
},
"text": {
"type": "string"
},
"type": {
"enum": [
"Plan"
],
"title": "PlanTurnItemType",
"type": "string"
}
},
"required": [
"id",
"text",
"type"
],
"title": "PlanTurnItem",
"type": "object"
},
{
"properties": {
"id": {
"type": "string"
},
"raw_content": {
"default": [],
"items": {
"type": "string"
},
"type": "array"
},
"summary_text": {
"items": {
"type": "string"
},
"type": "array"
},
"type": {
"enum": [
"Reasoning"
],
"title": "ReasoningTurnItemType",
"type": "string"
}
},
"required": [
"id",
"summary_text",
"type"
],
"title": "ReasoningTurnItem",
"type": "object"
},
{
"properties": {
"action": {
"$ref": "#/definitions/WebSearchAction2"
},
"id": {
"type": "string"
},
"query": {
"type": "string"
},
"type": {
"enum": [
"WebSearch"
],
"title": "WebSearchTurnItemType",
"type": "string"
}
},
"required": [
"action",
"id",
"query",
"type"
],
"title": "WebSearchTurnItem",
"type": "object"
},
{
"properties": {
"id": {
"type": "string"
},
"type": {
"enum": [
"ContextCompaction"
],
"title": "ContextCompactionTurnItemType",
"type": "string"
}
},
"required": [
"id",
"type"
],
"title": "ContextCompactionTurnItem",
"type": "object"
}
]
},
"TurnPlanStep": {
"properties": {
"status": {
"$ref": "#/definitions/TurnPlanStepStatus"
},
"step": {
"type": "string"
}
},
"required": [
"status",
"step"
],
"type": "object"
},
"TurnPlanStepStatus": {
"enum": [
"pending",
"inProgress",
"completed"
],
"type": "string"
},
"TurnPlanUpdatedNotification": {
"properties": {
"explanation": {
"type": [
"string",
"null"
]
},
"plan": {
"items": {
"$ref": "#/definitions/TurnPlanStep"
},
"type": "array"
},
"threadId": {
"type": "string"
},
"turnId": {
"type": "string"
}
},
"required": [
"plan",
"threadId",
"turnId"
],
"type": "object"
},
"TurnStartedNotification": {
"properties": {
"threadId": {
"type": "string"
},
"turn": {
"$ref": "#/definitions/Turn"
}
},
"required": [
"threadId",
"turn"
],
"type": "object"
},
"TurnStatus": {
"enum": [
"completed",
"interrupted",
"failed",
"inProgress"
],
"type": "string"
},
"UserInput": {
"oneOf": [
{
"properties": {
"text": {
"type": "string"
},
"text_elements": {
"default": [],
"description": "UI-defined spans within `text` used to render or persist special elements.",
"items": {
"$ref": "#/definitions/TextElement"
},
"type": "array"
},
"type": {
"enum": [
"text"
],
"title": "TextUserInputType",
"type": "string"
}
},
"required": [
"text",
"type"
],
"title": "TextUserInput",
"type": "object"
},
{
"properties": {
"type": {
"enum": [
"image"
],
"title": "ImageUserInputType",
"type": "string"
},
"url": {
"type": "string"
}
},
"required": [
"type",
"url"
],
"title": "ImageUserInput",
"type": "object"
},
{
"properties": {
"path": {
"type": "string"
},
"type": {
"enum": [
"localImage"
],
"title": "LocalImageUserInputType",
"type": "string"
}
},
"required": [
"path",
"type"
],
"title": "LocalImageUserInput",
"type": "object"
},
{
"properties": {
"name": {
"type": "string"
},
"path": {
"type": "string"
},
"type": {
"enum": [
"skill"
],
"title": "SkillUserInputType",
"type": "string"
}
},
"required": [
"name",
"path",
"type"
],
"title": "SkillUserInput",
"type": "object"
},
{
"properties": {
"name": {
"type": "string"
},
"path": {
"type": "string"
},
"type": {
"enum": [
"mention"
],
"title": "MentionUserInputType",
"type": "string"
}
},
"required": [
"name",
"path",
"type"
],
"title": "MentionUserInput",
"type": "object"
}
]
},
"UserInput2": {
"description": "User input",
"oneOf": [
{
"properties": {
"text": {
"type": "string"
},
"text_elements": {
"default": [],
"description": "UI-defined spans within `text` that should be treated as special elements. These are byte ranges into the UTF-8 `text` buffer and are used to render or persist rich input markers (e.g., image placeholders) across history and resume without mutating the literal text.",
"items": {
"$ref": "#/definitions/TextElement2"
},
"type": "array"
},
"type": {
"enum": [
"text"
],
"title": "TextUserInput2Type",
"type": "string"
}
},
"required": [
"text",
"type"
],
"title": "TextUserInput2",
"type": "object"
},
{
"description": "Pre‑encoded data: URI image.",
"properties": {
"image_url": {
"type": "string"
},
"type": {
"enum": [
"image"
],
"title": "ImageUserInput2Type",
"type": "string"
}
},
"required": [
"image_url",
"type"
],
"title": "ImageUserInput2",
"type": "object"
},
{
"description": "Local image path provided by the user. This will be converted to an `Image` variant (base64 data URL) during request serialization.",
"properties": {
"path": {
"type": "string"
},
"type": {
"enum": [
"local_image"
],
"title": "LocalImageUserInput2Type",
"type": "string"
}
},
"required": [
"path",
"type"
],
"title": "LocalImageUserInput2",
"type": "object"
},
{
"description": "Skill selected by the user (name + path to SKILL.md).",
"properties": {
"name": {
"type": "string"
},
"path": {
"type": "string"
},
"type": {
"enum": [
"skill"
],
"title": "SkillUserInput2Type",
"type": "string"
}
},
"required": [
"name",
"path",
"type"
],
"title": "SkillUserInput2",
"type": "object"
},
{
"description": "Explicit mention selected by the user (name + app://connector id).",
"properties": {
"name": {
"type": "string"
},
"path": {
"type": "string"
},
"type": {
"enum": [
"mention"
],
"title": "MentionUserInput2Type",
"type": "string"
}
},
"required": [
"name",
"path",
"type"
],
"title": "MentionUserInput2",
"type": "object"
}
]
},
"WebSearchAction": {
"oneOf": [
{
"properties": {
"queries": {
"items": {
"type": "string"
},
"type": [
"array",
"null"
]
},
"query": {
"type": [
"string",
"null"
]
},
"type": {
"enum": [
"search"
],
"title": "SearchWebSearchActionType",
"type": "string"
}
},
"required": [
"type"
],
"title": "SearchWebSearchAction",
"type": "object"
},
{
"properties": {
"type": {
"enum": [
"openPage"
],
"title": "OpenPageWebSearchActionType",
"type": "string"
},
"url": {
"type": [
"string",
"null"
]
}
},
"required": [
"type"
],
"title": "OpenPageWebSearchAction",
"type": "object"
},
{
"properties": {
"pattern": {
"type": [
"string",
"null"
]
},
"type": {
"enum": [
"findInPage"
],
"title": "FindInPageWebSearchActionType",
"type": "string"
},
"url": {
"type": [
"string",
"null"
]
}
},
"required": [
"type"
],
"title": "FindInPageWebSearchAction",
"type": "object"
},
{
"properties": {
"type": {
"enum": [
"other"
],
"title": "OtherWebSearchActionType",
"type": "string"
}
},
"required": [
"type"
],
"title": "OtherWebSearchAction",
"type": "object"
}
]
},
"WebSearchAction2": {
"oneOf": [
{
"properties": {
"queries": {
"items": {
"type": "string"
},
"type": [
"array",
"null"
]
},
"query": {
"type": [
"string",
"null"
]
},
"type": {
"enum": [
"search"
],
"title": "SearchWebSearchAction2Type",
"type": "string"
}
},
"required": [
"type"
],
"title": "SearchWebSearchAction2",
"type": "object"
},
{
"properties": {
"type": {
"enum": [
"open_page"
],
"title": "OpenPageWebSearchAction2Type",
"type": "string"
},
"url": {
"type": [
"string",
"null"
]
}
},
"required": [
"type"
],
"title": "OpenPageWebSearchAction2",
"type": "object"
},
{
"properties": {
"pattern": {
"type": [
"string",
"null"
]
},
"type": {
"enum": [
"find_in_page"
],
"title": "FindInPageWebSearchAction2Type",
"type": "string"
},
"url": {
"type": [
"string",
"null"
]
}
},
"required": [
"type"
],
"title": "FindInPageWebSearchAction2",
"type": "object"
},
{
"properties": {
"type": {
"enum": [
"other"
],
"title": "OtherWebSearchAction2Type",
"type": "string"
}
},
"required": [
"type"
],
"title": "OtherWebSearchAction2",
"type": "object"
}
]
},
"WindowsWorldWritableWarningNotification": {
"properties": {
"extraCount": {
"format": "uint",
"minimum": 0.0,
"type": "integer"
},
"failedScan": {
"type": "boolean"
},
"samplePaths": {
"items": {
"type": "string"
},
"type": "array"
}
},
"required": [
"extraCount",
"failedScan",
"samplePaths"
],
"type": "object"
}
},
"description": "Notification sent from the server to the client.",
"oneOf": [
{
"description": "NEW NOTIFICATIONS",
"properties": {
"method": {
"enum": [
"error"
],
"title": "ErrorNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/ErrorNotification"
}
},
"required": [
"method",
"params"
],
"title": "ErrorNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"thread/started"
],
"title": "Thread/startedNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/ThreadStartedNotification"
}
},
"required": [
"method",
"params"
],
"title": "Thread/startedNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"thread/name/updated"
],
"title": "Thread/name/updatedNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/ThreadNameUpdatedNotification"
}
},
"required": [
"method",
"params"
],
"title": "Thread/name/updatedNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"thread/tokenUsage/updated"
],
"title": "Thread/tokenUsage/updatedNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/ThreadTokenUsageUpdatedNotification"
}
},
"required": [
"method",
"params"
],
"title": "Thread/tokenUsage/updatedNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"turn/started"
],
"title": "Turn/startedNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/TurnStartedNotification"
}
},
"required": [
"method",
"params"
],
"title": "Turn/startedNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"turn/completed"
],
"title": "Turn/completedNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/TurnCompletedNotification"
}
},
"required": [
"method",
"params"
],
"title": "Turn/completedNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"turn/diff/updated"
],
"title": "Turn/diff/updatedNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/TurnDiffUpdatedNotification"
}
},
"required": [
"method",
"params"
],
"title": "Turn/diff/updatedNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"turn/plan/updated"
],
"title": "Turn/plan/updatedNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/TurnPlanUpdatedNotification"
}
},
"required": [
"method",
"params"
],
"title": "Turn/plan/updatedNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"item/started"
],
"title": "Item/startedNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/ItemStartedNotification"
}
},
"required": [
"method",
"params"
],
"title": "Item/startedNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"item/completed"
],
"title": "Item/completedNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/ItemCompletedNotification"
}
},
"required": [
"method",
"params"
],
"title": "Item/completedNotification",
"type": "object"
},
{
"description": "This event is internal-only. Used by Codex Cloud.",
"properties": {
"method": {
"enum": [
"rawResponseItem/completed"
],
"title": "RawResponseItem/completedNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/RawResponseItemCompletedNotification"
}
},
"required": [
"method",
"params"
],
"title": "RawResponseItem/completedNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"item/agentMessage/delta"
],
"title": "Item/agentMessage/deltaNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/AgentMessageDeltaNotification"
}
},
"required": [
"method",
"params"
],
"title": "Item/agentMessage/deltaNotification",
"type": "object"
},
{
"description": "EXPERIMENTAL - proposed plan streaming deltas for plan items.",
"properties": {
"method": {
"enum": [
"item/plan/delta"
],
"title": "Item/plan/deltaNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/PlanDeltaNotification"
}
},
"required": [
"method",
"params"
],
"title": "Item/plan/deltaNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"item/commandExecution/outputDelta"
],
"title": "Item/commandExecution/outputDeltaNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/CommandExecutionOutputDeltaNotification"
}
},
"required": [
"method",
"params"
],
"title": "Item/commandExecution/outputDeltaNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"item/commandExecution/terminalInteraction"
],
"title": "Item/commandExecution/terminalInteractionNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/TerminalInteractionNotification"
}
},
"required": [
"method",
"params"
],
"title": "Item/commandExecution/terminalInteractionNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"item/fileChange/outputDelta"
],
"title": "Item/fileChange/outputDeltaNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/FileChangeOutputDeltaNotification"
}
},
"required": [
"method",
"params"
],
"title": "Item/fileChange/outputDeltaNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"item/mcpToolCall/progress"
],
"title": "Item/mcpToolCall/progressNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/McpToolCallProgressNotification"
}
},
"required": [
"method",
"params"
],
"title": "Item/mcpToolCall/progressNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"mcpServer/oauthLogin/completed"
],
"title": "McpServer/oauthLogin/completedNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/McpServerOauthLoginCompletedNotification"
}
},
"required": [
"method",
"params"
],
"title": "McpServer/oauthLogin/completedNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"account/updated"
],
"title": "Account/updatedNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/AccountUpdatedNotification"
}
},
"required": [
"method",
"params"
],
"title": "Account/updatedNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"account/rateLimits/updated"
],
"title": "Account/rateLimits/updatedNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/AccountRateLimitsUpdatedNotification"
}
},
"required": [
"method",
"params"
],
"title": "Account/rateLimits/updatedNotification",
"type": "object"
},
[apps] Improve app loading. (#10994) There are two concepts of apps that we load in the harness: - Directory apps, which is all the apps that the user can install. - Accessible apps, which is what the user actually installed and can be $ inserted and be used by the model. These are extracted from the tools that are loaded through the gateway MCP. Previously we wait for both sets of apps before returning the full apps list. Which causes many issues because accessible apps won't be available to the UI or the model if directory apps aren't loaded or failed to load. In this PR we are separating them so that accessible apps can be loaded separately and are instantly available to be shown in the UI and to be provided in model context. We also added an app-server event so that clients can subscribe to also get accessible apps without being blocked on the full app list. - [x] Separate accessible apps and directory apps loading. - [x] `app/list` request will also emit `app/list/updated` notifications that app-server clients can subscribe. Which allows clients to get accessible apps list to render in the $ menu without being blocked by directory apps. - [x] Cache both accessible and directory apps with 1 hour TTL to avoid reloading them when creating new threads. - [x] TUI improvements to redraw $ menu and /apps menu when app list is updated.
2026-02-08 15:24:56 -08:00
{
"properties": {
"method": {
"enum": [
"app/list/updated"
],
"title": "App/list/updatedNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/AppListUpdatedNotification"
}
},
"required": [
"method",
"params"
],
"title": "App/list/updatedNotification",
"type": "object"
},
feat: vendor app-server protocol schema fixtures (#10371) Similar to what @sayan-oai did in openai/codex#8956 for `config.schema.json`, this PR updates the repo so that it includes the output of `codex app-server generate-json-schema` and `codex app-server generate-ts` and adds a test to verify it is in sync with the current code. Motivation: - This makes any schema changes introduced by a PR transparent during code review. - In particular, this should help us catch PRs that would introduce a non-backwards-compatible change to the app schema (eventually, this should also be enforced by tooling). - Once https://github.com/openai/codex/pull/10231 is in to formalize the notion of "experimental" fields, we can work on ensuring the non-experimental bits are backwards-compatible. `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the test and `just write-app-server-schema` can be use to generate the vendored schema files. Incidentally, when I run: ``` rg _ codex-rs/app-server-protocol/schema/typescript/v2 ``` I see a number of `snake_case` names that should be `camelCase`.
2026-02-01 23:38:43 -08:00
{
"properties": {
"method": {
"enum": [
"item/reasoning/summaryTextDelta"
],
"title": "Item/reasoning/summaryTextDeltaNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/ReasoningSummaryTextDeltaNotification"
}
},
"required": [
"method",
"params"
],
"title": "Item/reasoning/summaryTextDeltaNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"item/reasoning/summaryPartAdded"
],
"title": "Item/reasoning/summaryPartAddedNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/ReasoningSummaryPartAddedNotification"
}
},
"required": [
"method",
"params"
],
"title": "Item/reasoning/summaryPartAddedNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"item/reasoning/textDelta"
],
"title": "Item/reasoning/textDeltaNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/ReasoningTextDeltaNotification"
}
},
"required": [
"method",
"params"
],
"title": "Item/reasoning/textDeltaNotification",
"type": "object"
},
{
"description": "Deprecated: Use `ContextCompaction` item type instead.",
"properties": {
"method": {
"enum": [
"thread/compacted"
],
"title": "Thread/compactedNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/ContextCompactedNotification"
}
},
"required": [
"method",
"params"
],
"title": "Thread/compactedNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"deprecationNotice"
],
"title": "DeprecationNoticeNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/DeprecationNoticeNotification"
}
},
"required": [
"method",
"params"
],
"title": "DeprecationNoticeNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"configWarning"
],
"title": "ConfigWarningNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/ConfigWarningNotification"
}
},
"required": [
"method",
"params"
],
"title": "ConfigWarningNotification",
"type": "object"
},
{
"description": "Notifies the user of world-writable directories on Windows, which cannot be protected by the sandbox.",
"properties": {
"method": {
"enum": [
"windows/worldWritableWarning"
],
"title": "Windows/worldWritableWarningNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/WindowsWorldWritableWarningNotification"
}
},
"required": [
"method",
"params"
],
"title": "Windows/worldWritableWarningNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"account/login/completed"
],
"title": "Account/login/completedNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/AccountLoginCompletedNotification"
}
},
"required": [
"method",
"params"
],
"title": "Account/login/completedNotification",
"type": "object"
},
{
"description": "DEPRECATED NOTIFICATIONS below",
"properties": {
"method": {
"enum": [
"authStatusChange"
],
"title": "AuthStatusChangeNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/AuthStatusChangeNotification"
}
},
"required": [
"method",
"params"
],
"title": "AuthStatusChangeNotification",
"type": "object"
},
{
"description": "Deprecated: use `account/login/completed` instead.",
"properties": {
"method": {
"enum": [
"loginChatGptComplete"
],
"title": "LoginChatGptCompleteNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/LoginChatGptCompleteNotification"
}
},
"required": [
"method",
"params"
],
"title": "LoginChatGptCompleteNotification",
"type": "object"
},
{
"properties": {
"method": {
"enum": [
"sessionConfigured"
],
"title": "SessionConfiguredNotificationMethod",
"type": "string"
},
"params": {
"$ref": "#/definitions/SessionConfiguredNotification"
}
},
"required": [
"method",
"params"
],
"title": "SessionConfiguredNotification",
"type": "object"
}
],
"title": "ServerNotification"
fix(tui): keep unified exec summary on working line (#10962) ## Problem When unified-exec background sessions appear while the status indicator is visible, the bottom pane can grow by one row to show a dedicated footer line. That row insertion/removal makes the composer jump vertically and produces visible jitter/flicker during streaming turns. ## Mental model The bottom pane should expose one canonical background-exec summary string, but it should surface that string in only one place at a time: - if the status indicator row is visible, show the summary inline on that row; - if the status indicator row is hidden, show the summary as the standalone unified-exec footer row. This keeps status information visible while preserving a stable pane height. ## Non-goals This change does not alter unified-exec lifecycle, process tracking, or `/ps` behavior. It does not redesign status text copy, spinner timing, or interrupt handling semantics. ## Tradeoffs Inlining the summary preserves layout stability and keeps interrupt affordances in a fixed location, but it reduces horizontal space for long status/detail text in narrow terminals. We accept that truncation risk in exchange for removing vertical jitter and keeping the composer anchored. ## Architecture `UnifiedExecFooter` remains the source of truth for background-process summary copy via `summary_text()`. `BottomPane` mirrors that text into `StatusIndicatorWidget::update_inline_message()` whenever process state changes or a status widget is created. Rendering enforces single-surface output: the standalone footer row is skipped while status is present, and the status row appends the summary after the elapsed/interrupt segment. ## Documentation pass Added non-functional docs/comments that make the new invariant explicit: - status row owns inline summary when present; - unified-exec footer row renders only when status row is absent; - summary ordering keeps elapsed/interrupt affordance in a stable position. ## Observability No new telemetry or logs are introduced. The behavior is traceable through: - `BottomPane::set_unified_exec_processes()` for state updates, - `BottomPane::sync_status_inline_message()` for status-row synchronization, - `StatusIndicatorWidget::render()` for final inline ordering. ## Tests - Added `bottom_pane::tests::unified_exec_summary_does_not_increase_height_when_status_visible` to lock the no-height-growth invariant. - Updated the unified-exec status restoration snapshot to match inline rendering order. - Validated with: - `just fmt` - `cargo test -p codex-tui --lib` --------- Co-authored-by: Sayan Sisodiya <sayan@openai.com>
2026-02-09 14:25:32 -08:00
}
Reference in a new issue Copy permalink