Hmbown/CodeWhale · error · anyhow::Error

external credential access is disabled for {}

Error message

external credential access is disabled for {}

What it means

validate_read_scope() checks that a stored external-credential consent actually grants the access being attempted. Access == ExternalCredentialAccess::Disabled means consent exists but is explicitly switched off (revoked/denied), so any read attempt for that provider bails without touching the file — inventory surfaces can still show the dormant consent.

Source

Thrown at crates/config/src/external_credentials.rs:402

            source,
            path,
            consent_version: EXTERNAL_CREDENTIAL_CONSENT_VERSION,
        }
    }

    /// Validate that this record is a current read-only consent for one exact
    /// provider/source/path tuple without minting an I/O capability.
    ///
    /// This is intentionally side-effect free so inventory and picker surfaces
    /// can acknowledge dormant consent without inspecting the external file.
    pub fn validate_read_scope(
        &self,
        provider: ProviderKind,
        source: ExternalCredentialSource,
        resolved_path: &Path,
    ) -> Result<()> {
        if self.access == ExternalCredentialAccess::Disabled {
            bail!(
                "external credential access is disabled for {}",
                provider.as_str()
            );
        }
        if self.access == ExternalCredentialAccess::Managed {
            bail!(
                "managed external credential access is unsupported for {}; no schema-safe preservation adapter is available",
                provider.as_str()
            );
        }
        if self.consent_version != EXTERNAL_CREDENTIAL_CONSENT_VERSION {
            bail!(
                "external credential consent for {} uses unsupported version {}; revoke and consent again",
                provider.as_str(),
                self.consent_version
            );
        }
        if self.provider != provider.as_str() {

View on GitHub (pinned to 0c42157ee5)

Solutions

  1. Re-enable access by consenting again for that provider/source/path rather than editing the record by hand
  2. If the denial is intentional, stop selecting that external credential and use another auth source (env var, command, secret_id)

Example fix

# before: consent record with access = "disabled", provider still selected

# after: revoke and consent again
$ codewhale credentials revoke <provider> && codewhale credentials consent <provider> --path /keys/acme.env
Defensive patterns

Strategy: try-catch

Validate before calling

// Check the access level before attempting a read:
if consent.access == ExternalCredentialAccess::Disabled {
    // surface 're-consent required' in the UI instead of calling read APIs
}

Type guard

fn grants_read(access: ExternalCredentialAccess) -> bool {
    matches!(access, ExternalCredentialAccess::ReadOnly)
}

Try / catch

match consent.validate_read_scope(provider, source, &path) {
    Ok(()) => read_external_credential(&path),
    Err(e) if e.to_string().contains("access is disabled") => {
        // prompt the user to consent again; do not silently switch auth source
        prompt_reconsent(provider)
    }
    Err(e) => Err(e),
}

Prevention

When it happens

Trigger: A consent record for the provider exists in config with access = "disabled" and code paths call validate_read_scope(provider, source, path) intending to read the credential.

Common situations: User revoked consent (or a security policy set it to disabled) and later selects that provider/credential again; consent deliberately parked as disabled during audits; tooling that lists credentials then attempts reads without checking the access level.

Related errors

AI-assisted analysis of Hmbown/CodeWhale@0c42157ee5 (2026-08-20). Data as JSON: /api/errors/8f1558f798e702a0. Report an issue: GitHub.