warpdotdev/warp · error · anyhow::Error

Timed out waiting for Warp Drive to sync

Error message

Timed out waiting for Warp Drive to sync

What it means

Thrown when UpdateManager::as_ref(ctx).initial_load_complete() does not finish within WARP_DRIVE_SYNC_TIMEOUT (60 seconds, app/src/ai/agent_sdk/driver.rs:172). Warp Drive is the cloud-sync layer; initial_load_complete resolves only after the first full sync of drive objects. The timeout means the client never observed that initial sync completing.

Source

Thrown at app/src/ai/agent_sdk/common.rs:163

            .with_timeout(WORKSPACE_METADATA_REFRESH_TIMEOUT)
    });

    async move {
        let _ = refresh_future
            .await
            .map_err(|_| anyhow::anyhow!("Timed out refreshing team metadata"))?;
        Ok(())
    }
}

/// Refresh Warp Drive before executing an operation.
pub fn refresh_warp_drive(
    ctx: &AppContext,
) -> impl Future<Output = anyhow::Result<()>> + Send + 'static + use<> {
    UpdateManager::as_ref(ctx)
        .initial_load_complete()
        .with_timeout(WARP_DRIVE_SYNC_TIMEOUT)
        .map_err(|_| anyhow::anyhow!("Timed out waiting for Warp Drive to sync"))
}

/// Fetch the conversation's server metadata and validate that its harness matches the caller's
/// `--harness` choice. Returns the metadata on success so the caller can reuse it (e.g. for the
/// server conversation token).
///
/// Called up-front before any task/config-build logic consumes `args.harness`, so a mismatch
/// error surfaces before side effects like task creation. We deliberately do NOT auto-upgrade
/// the harness: `Harness::Oz` default with a Claude conversation id is treated as a mismatch
/// and errors out.
pub(super) async fn fetch_and_validate_conversation_harness(
    ai_client: Arc<dyn AIClient>,
    conversation_id: &str,
    args_harness: Harness,
) -> Result<ServerAIConversationMetadata, AgentDriverError> {
    let metadata = ai_client
        .list_ai_conversation_metadata(Some(vec![conversation_id.to_string()]))
        .await

View on GitHub (pinned to e72fd7aacb)

Solutions

1. Verify you are logged in and the Warp app has completed its first Drive sync (open the app once and let it finish), then retry the command.
2. Check connectivity/auth: expired credentials make initial_load_complete never resolve while retrying quietly.
3. For very large drives where 60s is genuinely too short, as a maintainer bump or make WARP_DRIVE_SYNC_TIMEOUT configurable.
4. If sync is optional for your flow, structure the caller to degrade gracefully instead of propagating the error.

Example fix

// before
UpdateManager::as_ref(ctx)
    .initial_load_complete()
    .with_timeout(WARP_DRIVE_SYNC_TIMEOUT)
    .map_err(|_| anyhow::anyhow!("Timed out waiting for Warp Drive to sync"))

// after (caller decides whether drive sync is mandatory)
if requires_drive {
    refresh_warp_drive(ctx).await?;
} else if let Err(err) = refresh_warp_drive(ctx).await {
    log::warn!("Warp Drive sync skipped: {err:#}");
}

if !UpdateManager::as_ref(ctx).has_completed_initial_load() {
    // not required, but lets you warn before burning the 60s timeout
    log::warn!("Warp Drive initial load still pending");
}

let mut attempt = 0;
loop {
    match refresh_warp_drive(ctx).await {
        Ok(()) => break,
        Err(err) if err.to_string().contains("Timed out waiting for Warp Drive to sync") && attempt < 1 => {
            attempt += 1;
            tokio::time::sleep(std::time::Duration::from_secs(5)).await;
        }
        Err(err) => return Err(err),
    }
}

When it happens

Trigger: Calling refresh_warp_drive(ctx) (or the environment-resolution paths in app/src/ai/agent_sdk/environment.rs that use the same constant) when the UpdateManager's initial load future stalls >60s — offline machine, auth failure preventing sync, large drive taking longer than 60s for first load, or websocket to the sync backend being down.

Common situations: First run of an ambient-agent/CLI command on a new machine before Warp Drive has synced; running with a logged-out or token-expired account; firewall blocking the sync websocket; or an unusually large synced workspace whose initial load exceeds the fixed 60s budget.

Understand the failure class

• Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

• Timed out refreshing team metadata
• Timed out waiting for Warp Drive to sync
• Failed to fetch images: {}
• Failed to fetch images: {err}
• Error polling OAuth status: {err}

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