astrid-runtime/astrid · error

daemon rejected capsule metadata request: {message}

Error message

daemon rejected capsule metadata request: {message}

What it means

Raised by `daemon_capsule_metadata` when the running astrid daemon answers a `GetCapsuleMetadata` request with a `KernelResponse::Error(message)` instead of capsule metadata. The daemon's own rejection reason is embedded in the message, so the root cause (auth, state, internal daemon failure) comes from the daemon side. Called by `update_daemon_capsules` and `regenerate_distro_lock`.

Source

Thrown at crates/astrid-cli/src/commands/capsule/install_update.rs:178

            &source,
            Some(name),
            workspace,
            false,
            approve_untrusted,
            &[],
        )
        .await
    } else {
        update_all_capsules(&home, &principal, workspace, approve_untrusted).await
    }
}

async fn daemon_capsule_metadata() -> anyhow::Result<Vec<CapsuleMetadataEntry>> {
    let mut client = crate::socket_client::connect_kernel_for_workspace(None).await?;
    match client.request(KernelRequest::GetCapsuleMetadata).await? {
        KernelResponse::CapsuleMetadata(entries) => Ok(entries),
        KernelResponse::Error(message) => {
            bail!("daemon rejected capsule metadata request: {message}")
        },
        other => bail!("unexpected daemon response: {other:?}"),
    }
}

async fn update_daemon_capsules(
    target: Option<&str>,
    principal: &astrid_core::PrincipalId,
    approve_untrusted: bool,
) -> anyhow::Result<()> {
    let entries = daemon_capsule_metadata().await?;
    if let Some(name) = target {
        let entry = entries
            .into_iter()
            .find(|entry| entry.name == name)
            .ok_or_else(|| anyhow::anyhow!("Capsule '{name}' is not installed."))?;
        let Some(source) = entry.update_source else {
            eprintln!(

View on GitHub (pinned to affd8760f4)

Solutions

  1. Read the daemon's reason embedded in the message and address it directly.
  2. Restart the daemon so it rebuilds its capsule metadata state, then retry.
  3. Ensure the daemon and CLI versions match; upgrade the daemon after a CLI upgrade.
  4. If the metadata store is corrupt, reinstall the affected capsules to rebuild daemon-side metadata.

Example fix

// before: daemon started before CLI upgrade, rejects request
astrid capsule update
// error: daemon rejected capsule metadata request: unsupported request version

// after: restart/upgrade the daemon to match the CLI
astrid daemon restart
astrid capsule update
Defensive patterns

Strategy: try-catch

Try / catch

match daemon_capsule_metadata().await {
    Ok(entries) => update_all(entries),
    Err(e) if e.to_string().starts_with("daemon rejected capsule metadata request") => {
        eprintln!("{e:#}\nHint: restart the daemon and ensure CLI/daemon versions match.");
        std::process::exit(1);
    },
    Err(e) => return Err(e),
}

Prevention

When it happens

Trigger: Running `astrid capsule update` (non-workspace mode) or refreshing the distro lock when the daemon responds Error to `KernelRequest::GetCapsuleMetadata` — e.g. daemon's capsule registry is in a bad state, permissions failure, or an internal daemon error string.

Common situations: Daemon version mismatch with the CLI sending a request it mishandles; daemon's metadata store corrupted or unreadable; daemon not fully initialized after start; version-skew after an upgrade where the old daemon rejects new request semantics.

Related errors


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