Cannot remove '{name}': it is the sole provider of '{}' whic

Error message

Cannot remove '{name}': it is the sole provider of '{}' which is required by '{}'. Use --force to override.

What it means

Before removing a workspace capsule, the CLI runs check_removal_safety against all installed capsules. If the target is the sole provider of a capability that another installed capsule depends on, removal would break that dependent, so it bails and names the capability and dependent capsule, suggesting --force. This guards the workspace dependency graph from accidental breakage.

Source

Thrown at crates/astrid-cli/src/commands/capsule/remove.rs:201

    if !target_dir.exists() {
        bail!("Capsule '{name}' is not installed.");
    }

    let target_meta = super::meta::read_meta(&target_dir);

    // Scan once, reuse for both dependency check and binary cleanup
    let all_capsules =
        astrid_capsule_install::meta::scan_installed_capsules_in_home_for_in_workspace(
            home,
            principal,
            workspace_root,
            crate::workspace_layout::current(),
        )?;

    // Dependency safety check (skip with --force)
    if !force && let Some(block) = check_removal_safety(name, target_meta.as_ref(), &all_capsules) {
        bail!(
            "Cannot remove '{name}': it is the sole provider of '{}' \
             which is required by '{}'. Use --force to override.",
            block.capability,
            block.dependent,
        );
    }

    Ok(())
}

/// A blocked removal: the target capsule is the sole provider of a capability
/// that another capsule requires.
struct RemovalBlocked {
    capability: String,
    dependent: String,
}

/// Check whether removing `target_name` would leave any required capability

View on GitHub (pinned to affd8760f4)

Solutions

Remove or update the dependent capsule first so it no longer needs the capability.
If you accept the breakage, re-run with --force: astrid capsule remove <name> --workspace --force.
Inspect the dependency report (capsule list / show) to see which capsules consume the capability before deciding.

Example fix

// before
astrid capsule remove logging-lib --workspace            // blocked: required by 'ingest'
// after
astrid capsule remove logging-lib --workspace --force    // explicit override
// or: remove/update 'ingest' first

Defensive patterns

Strategy: validation

Validate before calling

// dry-run the dependency check before removing
if let Some(block) = check_removal_safety(name, meta, &all_capsules) {
    eprintln!("would block: {} needed by {}", block.capability, block.dependent);
}

Type guard

fn is_dependency_block(e: &anyhow::Error) -> bool {
    e.to_string().contains("sole provider")
}

Try / catch

if let Err(e) = remove_capsule(...).await {
    if is_dependency_block(&e) {
        // surface block.capability/block.dependent, require explicit --force
    } else { return Err(e); }
}

Prevention

Inspect dependents with capsule show before removing shared capsules.
Never pass --force blindly in scripts; prompt the operator.
Plan capability ownership so shared capsules have explicit maintainers.

When it happens

Trigger: astrid capsule remove <name> --workspace without --force when another installed capsule's dependencies resolve to this capsule as the only provider of some capability.

Common situations: Removing a shared utility/library capsule that several agents' capsules depend on; cleaning up 'unused-looking' capsules in a shared workspace; scripted bulk removals that ignore the graph.

Related errors

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