What causes "reading password failed: {status}" in zed-industries/zed?

Look up the numeric status in OSStatus tables to identify the failure class (-34018 entitlement, -25293 auth, -25308 interaction, -25291 unavailable)

zed-industries/zed · error

reading password failed: {status}

Error message

reading password failed: {status}

What it means

On macOS, reading a stored password queries the keychain via SecItemCopyMatching for internet passwords matching the server URL. Success (errSecSuccess), errSecItemNotFound and errSecUserCanceled are handled specially; every other OSStatus takes this bail with the raw code. Frequent codes: -25293 errSecAuthFailed, -25291 errSecNotAvailable, -25308 errSecInteractionNotAllowed, -34018 errSecMissingEntitlement.

Source

Thrown at crates/gpui_macos/src/platform.rs:1237

    fn read_credentials(&self, url: &str) -> Task<Result<Option<(String, Vec<u8>)>>> {
        let url = url.to_string();
        self.background_executor().spawn(async move {
            let url = CFString::from(url.as_str());
            let cf_true = CFBoolean::true_value().as_CFTypeRef();

            unsafe {
                use security::*;

                // Find any credentials for the given server URL.
                let mut attrs = CFMutableDictionary::with_capacity(5);
                attrs.set(kSecClass as *const _, kSecClassInternetPassword as *const _);
                attrs.set(kSecAttrServer as *const _, url.as_CFTypeRef());
                attrs.set(kSecReturnAttributes as *const _, cf_true);
                attrs.set(kSecReturnData as *const _, cf_true);

                let mut result = CFTypeRef::from(ptr::null());
                let status = SecItemCopyMatching(attrs.as_concrete_TypeRef(), &mut result);
                match status {
                    security::errSecSuccess => {}
                    security::errSecItemNotFound | security::errSecUserCanceled => return Ok(None),
                    _ => anyhow::bail!("reading password failed: {status}"),
                }

                let result = CFType::wrap_under_create_rule(result)
                    .downcast::<CFDictionary>()
                    .context("keychain item was not a dictionary")?;
                let username = result
                    .find(kSecAttrAccount as *const _)
                    .context("account was missing from keychain item")?;
                let username = CFType::wrap_under_get_rule(*username)
                    .downcast::<CFString>()
                    .context("account was not a string")?;
                let password = result
                    .find(kSecValueData as *const _)
                    .context("password was missing from keychain item")?;

View on GitHub (pinned to 9d272b0363)

Solutions

Look up the numeric status in OSStatus tables to identify the failure class (-34018 entitlement, -25293 auth, -25308 interaction, -25291 unavailable)
If -34018 or -25293: verify code signing and keychain-access entitlements on the build
If -25308 or a locked keychain: perform the read while a UI session exists or prompt the user to unlock
Degrade gracefully: catch the error and prompt the user to re-enter credentials, then re-store them

Defensive patterns

Strategy: try-catch

Try / catch

match keychain.read_password(&url).await {
    Ok(Some(cred)) => use_credentials(cred),
    Ok(None) => prompt_for_credentials().await,
    Err(err) => {
        // auth failed / missing entitlement / unavailable: never crash on keychain state
        log::warn!("keychain read failed: {err}");
        prompt_for_credentials().await
    }
}

Prevention

Never assume keychain reads succeed; always offer an interactive fallback
Map known OSStatus codes to actionable user messages
Test credential flows in signed builds with correct entitlements, not only via cargo run

When it happens

Trigger: Keychain locked or access to the item denied (auth failed); missing keychain-access entitlement in a sandboxed or unsigned build; no keychain available (SSH/CI session without a user login); item access requiring UI interaction in a context that forbids it.

Common situations: Dev builds run without proper code signing or entitlements; hardened runtime blocking keychain access; corrupted keychain or changed item ACLs after re-signing; credentials code first tested only via cargo run.

Related errors

AI-assisted analysis of zed-industries/zed@9d272b0363 (2026-08-20). Data as JSON: /api/errors/c723306aa72fd522. Report an issue: GitHub.