could not clear the Codewhale-owned legacy

Error message

could not clear the Codewhale-owned legacy {slot} secret slot: {error}; config was not changed

What it means

After successfully snapshotting the legacy Antigravity secret, the migration deletes the slot via secrets.delete(slot). If the delete fails, the in-memory config changes are rolled back and this error is returned; the message includes the backend error and the reassurance that the config was not changed.

Solutions

Check permissions on the secret store entry and grant the CLI delete rights
Unlock the keychain/secret service before running the migration
Manually delete the legacy slot via the OS keyring tool, then re-run the migration
Retry; transient backend failures leave config untouched so the migration is idempotent

Defensive patterns

Strategy: retry

Validate before calling

// check the slot is readable AND writable-adjacent (delete rights) before migrating
if secrets.get(slot).is_err() { eprintln!("cannot read slot; do not attempt clear"); }

Try / catch

loop {
    match clear_legacy_antigravity_config(store, secrets) {
        Ok(()) => break,
        Err(e) if e.to_string().contains("could not clear") && attempts < 3 => attempts += 1,
        Err(e) => return Err(e),
    }
}

Prevention

Grant the CLI delete permission on its keyring items
Avoid read-only or policy-locked secret stores for accounts running migrations
Because failures roll back config, retries are safe — retry after unlocking the backend

When it happens

Trigger: `secrets.delete(slot)` returns Err for the Antigravity slot — e.g. the secret backend refuses deletion (permissions, read-only store) or the backend connection drops between get and delete.

Common situations: A read-only or policy-restricted keyring, SELinux/permission issues on the secret store, or keychain items locked against modification during automated migration runs.

Understand the failure class

Background: "Permission denied" / "Failed to write" file errors: why a library can't write its files to disk (EACCES, EPERM, ENOSPC) and how to fix them — this error's family across 43 libraries.

Related errors

AI-assisted analysis of Hmbown/CodeWhale@73e0f67d83 (2026-09-22). Data as JSON: /api/errors/b25f950251679499. Report an issue: GitHub.

Appendix: source

Thrown at crates/cli/src/lib.rs:2705

    let prior_secret = secrets.get(slot).map_err(|error| {
        anyhow!(
            "could not snapshot the Codewhale-owned legacy {slot} secret slot before clearing it: {error}; config was not changed"
        )
    })?;

    store.config.providers.antigravity = Default::default();
    store
        .config
        .fallback_providers
        .retain(|fallback| *fallback != provider);
    if store.config.provider == provider {
        store.config.provider = ProviderKind::default();
        store.config.selected_provider_id = None;
    }

    if let Err(error) = secrets.delete(slot) {
        store.config = original_config;
        return Err(anyhow!(
            "could not clear the Codewhale-owned legacy {slot} secret slot: {error}; config was not changed"
        ));
    }

    if let Err(error) = store.save() {
        store.config = original_config;
        if let Some(previous) = prior_secret {
            let current = secrets.get(slot).map_err(|rollback| {
                anyhow!(
                    "{error}; additionally could not verify rollback of the Codewhale-owned legacy {slot} secret slot: {rollback}"
                )
            })?;
            match current {
                None => secrets.set(slot, &previous).map_err(|rollback| {
                    anyhow!(
                        "{error}; additionally failed to restore the Codewhale-owned legacy {slot} secret slot: {rollback}"
                    )
                })?,

View on GitHub (pinned to 73e0f67d83)