What causes "File is too large ({}MB). Maximum size is 10MB." in warpdotdev/warp?

Compress or split the file to under 10MB (re-encode the screenshot, gzip logs, crop the export).

warpdotdev/warp · error · anyhow::Error

File is too large ({}MB). Maximum size is 10MB.

Error message

File is too large ({}MB). Maximum size is 10MB.

What it means

Thrown by process_attachment when the fully-read file exceeds MAX_ATTACHMENT_SIZE_BYTES (10 * 1024 * 1024, app/src/ai/attachment_utils.rs:7). All attachment types share this single limit; the reported size is integer-divided by 1MB, so a 10.5MB file shows as 10MB.

Source

Thrown at app/src/ai/agent_sdk/driver/attachments.rs:305

        )
    })?;

    // Detect MIME type from file data using infer crate, fall back to file extension
    let mime_type = if file_bytes.len() >= MIN_IMAGE_HEADER_SIZE {
        infer::get(&file_bytes).map(|kind| kind.mime_type().to_string())
    } else {
        None
    };

    // If infer couldn't detect, fall back to file extension
    let mime_type = mime_type.unwrap_or_else(|| {
        from_path(attachment_path)
            .first_or_octet_stream()
            .to_string()
    });

    if file_bytes.len() > MAX_ATTACHMENT_SIZE_BYTES {
        return Err(anyhow::anyhow!(
            "File is too large ({}MB). Maximum size is 10MB.",
            file_bytes.len() / (1024 * 1024)
        ));
    }

    let base64_data = general_purpose::STANDARD.encode(&file_bytes);

    let file_name = attachment_path
        .file_name()
        .and_then(|n| n.to_str())
        .map(|s| s.to_string())
        .unwrap_or_else(|| format!("task_attachment_{index}"));

    Ok(AttachmentInput {
        file_name,
        mime_type,
        data: base64_data,
    })

View on GitHub (pinned to e72fd7aacb)

Solutions

Compress or split the file to under 10MB (re-encode the screenshot, gzip logs, crop the export).
For text content, paste an excerpt inline in the task instead of attaching the whole file.
If a larger limit is genuinely needed, ask maintainers to raise MAX_ATTACHMENT_SIZE_BYTES — server-side upload caps must agree.

Example fix

// before (CLI)
warp agent run --attach build/logs-full.txt

// after
gzip -9 build/logs-full.txt   # then attach the .gz if < 10MB, or:
head -c 10485760 build/logs-full.txt > build/logs-excerpt.txt

Defensive patterns

Strategy: validation

Validate before calling

const MAX: u64 = 10 * 1024 * 1024;
let len = std::fs::metadata(&path)?.len();
anyhow::ensure!(len <= MAX, "attachment is {} bytes; limit is {}", len, MAX);

Type guard

fn within_attachment_limit(p: &std::path::Path) -> bool {
    std::fs::metadata(p).map(|m| m.len() <= 10 * 1024 * 1024).unwrap_or(false)
}

Try / catch

if let Err(err) = process_attachment(&path, index) {
    if err.to_string().contains("File is too large") {
        // compress/split then retry once with the smaller artifact
    } else { return Err(err); }
}

Prevention

Check file size with fs::metadata before attaching — cheaper than a full read that then fails.
Remember the 10MB limit is shared by ALL attachment types, including images.
Compress screenshots (PNG → optimized) and gzip logs before attaching.

When it happens

Trigger: Calling process_attachment with a file whose byte length exceeds 10,485,760 — e.g. screenshots from retina displays, log bundles, datasets, or videos passed as agent task attachments. The check happens after the full read, right before base64 encoding.

Common situations: Large PNGs/exported PDFs exceeding 10MB; log archives zipped for debugging; users assuming images have a higher limit than other files (they do not — one shared limit); note the truncating integer division makes a 10.9MB file confusingly print '10MB' as if it were at the limit.

Related errors

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