The 'conversation' subcommand is not available in this build

Error message

The 'conversation' subcommand is not available in this build

What it means

The `warp task conversation` subcommand is gated behind the ConversationApi feature flag. On builds without it, dispatching any ConversationCommand (currently `get`) errors immediately before a server request is made.

Source

Thrown at app/src/ai/agent_sdk/mod.rs:602

    command: TaskCommand,
) -> anyhow::Result<()> {
    match command {
        TaskCommand::List(args) => ambient::list_ambient_agent_tasks(ctx, global_options, args),
        TaskCommand::Get(args) => {
            if args.conversation {
                if !FeatureFlag::ConversationApi.is_enabled() {
                    return Err(anyhow::anyhow!(
                        "The --conversation flag is not available in this build"
                    ));
                }
                ambient::get_run_conversation(ctx, args.task_id)
            } else {
                ambient::get_ambient_agent_task_status(ctx, global_options, args)
            }
        }
        TaskCommand::Conversation(conv_cmd) => {
            if !FeatureFlag::ConversationApi.is_enabled() {
                return Err(anyhow::anyhow!(
                    "The 'conversation' subcommand is not available in this build"
                ));
            }
            match conv_cmd {
                warp_cli::task::ConversationCommand::Get(args) => {
                    ambient::get_conversation(ctx, args.conversation_id)
                }
            }
        }
        TaskCommand::Message(message_cmd) => ambient::run_message(ctx, global_options, message_cmd),
    }
}

/// Singleton model that provides a ModelContext for spawning async operations
/// when starting the agent driver. This is needed because conversation fetching
/// requires spawning an async task, which requires a ModelContext.
struct AgentDriverRunner;

View on GitHub (pinned to e72fd7aacb)

Solutions

Use a build with the ConversationApi flag enabled
Fall back to `warp task get <task_id>` which works without the conversation API
Probe the CLI build's capabilities before scripting the subcommand

Example fix

# before
warp task conversation get abc123   # build without ConversationApi

# after
warp task get abc123   # on a ConversationApi-enabled build keep the original command

Defensive patterns

Strategy: validation

Validate before calling

# Feature-probe the subcommand, then fall back
task_out() { warp task conversation get "$1" 2>&1; }
out=$(task_out "$CONV_ID") || case "$out" in *'not available in this build'*) warp task get "$TASK_ID";; *) echo "$out" >&2; exit 1;; esac
echo "$out"

Try / catch

out=$(warp task conversation get "$id" 2>&1) || { case "$out" in *"subcommand is not available"*) warp task get "$task_id";; *) echo "$out" >&2; exit 1;; esac; }

Prevention

Check build capability probes in wrapper libraries instead of assuming subcommands
Version-gate automation: only call `task conversation` when the CLI version is known to ship ConversationApi

When it happens

Trigger: `warp task conversation get <conversation_id>` on a build where `FeatureFlag::ConversationApi.is_enabled()` is false.

Common situations: Dogfood-authored scripts executed on stable builds; client/server conversation API version skew; automation copied between environments with different flag sets.

Related errors

AI-assisted analysis of warpdotdev/warp@e72fd7aacb (2026-08-16). Data as JSON: /api/errors/b5d0c17ed7405ecb. Report an issue: GitHub.