Enum StandardRequest 

pub enum StandardRequest<T = Value>
where
    T: Serialize + DeserializeOwned + JsonSchema,
{
    Confirm {
        message: String,
        default: Option<bool>,
    },
    Prompt {
        message: String,
        default: Option<T>,
        placeholder: Option<String>,
    },
    Select {
        message: String,
        options: Vec<SelectOption<T>>,
        multi_select: bool,
    },
    Custom {
        data: T,
    },
}

Standard request types for common interactive UI patterns.

These request types cover the most common server-to-client interactions:

• Confirm: Yes/no questions before important actions
• Prompt: Free-form text input from the user
• Select: Choose one or more options from a list
• Custom: Domain-specific request payload

The type parameter T defaults to serde_json::Value for backwards compatibility. Use a custom type for domain-specific interactions.

For domain-specific interactions (e.g., image quality selection, custom dialogs), define your own request/response enums and use BidirChannel<YourRequest, YourResponse>.

Wire Format

Uses internally-tagged JSON (#[serde(tag = "type")]):

// Confirm request
{
  "type": "confirm",
  "message": "Delete 3 files?",
  "default": false
}

// Prompt request
{
  "type": "prompt",
  "message": "Enter project name:",
  "default": "my-project",
  "placeholder": "project-name"
}

// Select request
{
  "type": "select",
  "message": "Choose template:",
  "options": [
    { "value": "minimal", "label": "Minimal", "description": "Bare-bones starter" },
    { "value": "full", "label": "Full Featured" }
  ],
  "multiSelect": false
}

Client Implementation

Clients should display appropriate UI for each request type:

Type	UI Suggestion
confirm	Yes/No buttons or checkbox
prompt	Text input field
select	Dropdown, radio buttons, or checkbox list
custom	Application-defined

Variants

Confirm

Binary yes/no confirmation request.

Use this for important decisions like:

• Confirming destructive operations (“Delete 3 files?”)
• Proceeding with potentially expensive operations
• Accepting terms or conditions

The default field suggests the default choice if the user doesn’t explicitly respond (e.g., just presses Enter).

Fields

message: String

Question to ask the user. Should be a clear yes/no question.

default: Option<bool>

Default answer if user accepts without explicit choice.

• Some(true) = default to “yes”
• Some(false) = default to “no”
• None = require explicit choice

Prompt

Free-form text input request.

Use this for collecting:

• Names, titles, identifiers
• Paths, URLs
• Custom values not in a predefined list

For password/sensitive input, clients should use appropriate input masking.

Fields

message: String

Prompt message shown to the user.

default: Option<T>

Default value to pre-fill in the input. User can accept or modify.

placeholder: Option<String>

Placeholder text shown when input is empty. Provides a hint about expected format.

Select

Selection request for choosing from options.

Use this when the valid choices are known ahead of time. Supports both single and multiple selection.

Example

let options = vec![
    SelectOption::new("dev", "Development")
        .with_description("Local dev environment"),
    SelectOption::new("prod", "Production")
        .with_description("Live servers"),
];
let selected = ctx.select("Choose environment:", options).await?;

Fields

message: String

Selection prompt shown to the user.

options: Vec<SelectOption<T>>

Available options to choose from. Each option has a value (returned) and label (displayed).

multi_select: bool

Whether to allow selecting multiple options.

• false (default): single selection, returns one value
• true: multiple selection, returns zero or more values

Custom

Custom domain-specific request payload.

Use this for application-specific interactions that don’t fit the standard confirm/prompt/select patterns.

Fields

data: T

The custom request data.

Trait Implementations

impl<T> Clone for StandardRequest<T>

where T: Clone + Serialize + DeserializeOwned + JsonSchema,

fn clone(&self) -> StandardRequest<T>

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl<T> Debug for StandardRequest<T>

where T: Debug + Serialize + DeserializeOwned + JsonSchema,

fn fmt(&self, f: &mut Formatter<'_>) -> Result<(), Error>

Formats the value using the given formatter.

impl<'de, T> Deserialize<'de> for StandardRequest<T>

where T: Serialize + DeserializeOwned + JsonSchema,

fn deserialize<__D>( __deserializer: __D, ) -> Result<StandardRequest<T>, <__D as Deserializer<'de>>::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl<T> JsonSchema for StandardRequest<T>

where T: Serialize + DeserializeOwned + JsonSchema,

fn schema_name() -> Cow<'static, str>

The name of the generated JSON Schema.

fn schema_id() -> Cow<'static, str>

Returns a string that uniquely identifies the schema produced by this type.

fn json_schema(generator: &mut SchemaGenerator) -> Schema

Generates a JSON Schema for this type.

fn inline_schema() -> bool

Whether JSON Schemas generated for this type should be included directly in parent schemas, rather than being re-used where possible using the $ref keyword.

impl<T> PartialEq for StandardRequest<T>

where T: PartialEq + Serialize + DeserializeOwned + JsonSchema,

fn eq(&self, other: &StandardRequest<T>) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl<T> Serialize for StandardRequest<T>

where T: Serialize + DeserializeOwned + JsonSchema,

fn serialize<__S>( &self, __serializer: __S, ) -> Result<<__S as Serializer>::Ok, <__S as Serializer>::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl<T> StructuralPartialEq for StandardRequest<T>

where T: Serialize + DeserializeOwned + JsonSchema,