native provider identity does not match the co-installed exe

Error message

native provider identity does not match the co-installed executable

What it means

After checking the protocol version, validate_response validates the provider identity block returned by the native provider: the provider name must match the co-installed executable's expected name, the version string must be non-empty, at most 128 chars, free of control characters, and the capability list must have at most 16 unique entries. Any violation bails with this error because a mismatched identity means the response may come from a different (possibly malicious or stale) provider binary.

Source

Thrown at crates/astrid-cli/src/commands/storage.rs:232

) -> Result<()> {
    if response.protocol_version != STORAGE_PROVIDER_PROTOCOL_V1 {
        bail!(
            "{provider_name} protocol mismatch: expected {}, received {}",
            STORAGE_PROVIDER_PROTOCOL_V1,
            response.protocol_version
        );
    }
    if response.request_id != request.request_id {
        bail!("{provider_name} returned a response for a different request");
    }
    if response.provider.name != provider_name
        || response.provider.version.is_empty()
        || response.provider.version.len() > 128
        || response.provider.version.chars().any(char::is_control)
        || response.provider.capabilities.len() > 16
        || !capabilities_are_unique(&response.provider.capabilities)
    {
        bail!("native provider identity does not match the co-installed executable");
    }
    for capability in required_capabilities {
        if !response.provider.capabilities.contains(capability) {
            bail!("{provider_name} does not advertise required capability {capability:?}");
        }
    }
    let operation_matches = matches!(
        (&request.operation, &response.outcome),
        (
            StorageProviderOperationV1::Mount { .. },
            StorageProviderOutcomeV1::Success(StorageProviderSuccessV1::Mounted { .. })
        ) | (
            StorageProviderOperationV1::Sync { .. },
            StorageProviderOutcomeV1::Success(StorageProviderSuccessV1::Synced { .. })
        ) | (
            StorageProviderOperationV1::Status { .. },
            StorageProviderOutcomeV1::Success(StorageProviderSuccessV1::Status { .. })
        ) | (

View on GitHub (pinned to affd8760f4)

Solutions

Reinstall the co-installed native provider so name/version match what the CLI expects
Fix the provider to emit a clean, non-empty version string without control characters and a deduplicated capability list
Verify the provider binary path resolution isn't picking up a stale binary from another install
Add provider-side validation that sanitizes version and deduplicates capabilities before responding

Example fix

// before
capabilities: vec!["mount".into(), "mount".into(), "unmount".into()],
// after
capabilities: vec!["mount".into(), "unmount".into()],

Defensive patterns

Strategy: validation

Validate before calling

fn identity_ok(name: &str, p: &StorageProviderIdentityV1) -> bool { p.name == name && !p.version.is_empty() && p.version.len() <= 128 && !p.version.chars().any(char::is_control) && p.capabilities.len() <= 16 }

Type guard

fn has_unique_capabilities(caps: &[String]) -> bool { caps.len() <= 16 && caps.iter().collect::<std::collections::HashSet<_>>().len() == caps.len() }

Try / catch

match validate_provider_identity(&resp.provider, expected_name) {
    Ok(()) => {},
    Err(e) => eprintln!("reinstall the storage provider: {e}"),
}

Prevention

Keep provider binary and CLI installed as a matched pair
Sanitize version strings (no control chars, <=128 chars) in the provider
Deduplicate capability lists before serializing responses

When it happens

Trigger: The provider response's provider.name differs from the invoked provider_name, or version is empty/too long/contains control chars, or capabilities list exceeds 16 entries or contains duplicates — checked in validate_response.

Common situations: A leftover or replaced provider binary of a different build sits at the co-install path; a provider sends a debug version string with newline/control characters; a provider pads its capability list with duplicate entries; PATH or install layout points at an old provider version.

Understand the failure class

Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.

Related errors

AI-assisted analysis of astrid-runtime/astrid@affd8760f4 (2026-09-09). Data as JSON: /api/errors/d7edd26fc8642ef6. Report an issue: GitHub.