Hmbown/CodeWhale · error · anyhow::Error

Antigravity cloud-code does not accept role {other:?}

Error message

Antigravity cloud-code does not accept role {other:?}

What it means

The cloud-code request builder maps each message role and only accepts `user`, `assistant`, and `model` (aliased). Any other role string is surfaced verbatim in the bail message. This is a strict contract check: cloud-code's contents array has no representation for other roles, so the builder refuses rather than mislabeling the message.

Source

Thrown at crates/tui/src/client/cloud_code.rs:66

    };
    if has_system_text {
        return Err(CloudCodeRequestError::SystemPromptUnsupported.into());
    }
    if request
        .tools
        .as_ref()
        .is_some_and(|tools| !tools.is_empty())
    {
        bail!(
            "Antigravity cloud-code tools are not implemented yet; send a text-only turn or use the google provider"
        );
    }
    let mut contents = Vec::new();
    for message in &request.messages {
        let role = match message.role.as_str() {
            "user" => "user",
            "assistant" | "model" => "model",
            other => bail!("Antigravity cloud-code does not accept role {other:?}"),
        };
        let mut parts = Vec::new();
        for block in &message.content {
            match block {
                ContentBlock::Text { text, .. } if !text.trim().is_empty() => {
                    parts.push(json!({ "text": text }));
                }
                ContentBlock::Text { .. } => {}
                _ => bail!(
                    "Antigravity cloud-code accepts text parts only; non-text content fails closed"
                ),
            }
        }
        if !parts.is_empty() {
            contents.push(json!({ "role": role, "parts": parts }));
        }
    }
    if contents.is_empty() {

View on GitHub (pinned to 0c42157ee5)

Solutions

  1. Remove or convert `system` messages before sending on this route (note cloud-code rejects system prompts entirely)
  2. Drop `tool` role messages; tools are unsupported on this adapter anyway
  3. Normalize roles: map `model`→assistant upstream so only user/assistant remain

Example fix

// before
messages.push(Message { role: "system".into(), .. }); // -> bail role "system"

// after
let messages: Vec<_> = messages.into_iter().filter(|m| matches!(m.role.as_str(), "user" | "assistant" | "model")).collect();
Defensive patterns

Strategy: validation

Validate before calling

for msg in &request.messages {
    anyhow::ensure!(
        matches!(msg.role.as_str(), "user" | "assistant" | "model"),
        "cloud-code rejects role {:?}",
        msg.role
    );
}

Type guard

fn cloud_code_roles_ok(messages: &[ChatMessage]) -> bool {
    messages.iter().all(|m| matches!(m.role.as_str(), "user" | "assistant" | "model"))
}

Try / catch

let request = sanitize_roles_for_cloud_code(request)?; // filter system/tool first
match client.create_message_stream(request).await {
    Ok(s) => Ok(s),
    Err(err) if err.to_string().contains("does not accept role") => {
        Err(anyhow!("role rejected: sanitize message list before antigravity routes"))
    }
    Err(err) => Err(err),
}

Prevention

When it happens

Trigger: A message whose `role` is anything besides user/assistant/model — most commonly `system` or `tool` — reaching the builder on an antigravity route. The message content itself does not matter; the role alone triggers it.

Common situations: A pipeline that injects `system` messages into the message list (cloud-code wants no system prompt at all, which is the separate SystemPromptUnsupported error), or tool-result messages with role `tool` from a generic agent loop replayed onto this provider.

Related errors

AI-assisted analysis of Hmbown/CodeWhale@0c42157ee5 (2026-08-20). Data as JSON: /api/errors/0754e33d676dde2f. Report an issue: GitHub.