zeroclaw-labs/zeroclaw · error · anyhow::Error

Unsupported auth profile schema version {} (max supported: {

Error message

Unsupported auth profile schema version {} (max supported: {})

What it means

`read_persisted_locked` rejects an auth-profiles.json whose `schema_version` exceeds `CURRENT_SCHEMA_VERSION` (1). A version of 0 is tolerated and silently upgraded; anything above the compiled-in maximum means the file was written by a newer ZeroClaw and may contain fields this binary cannot safely interpret. Because every store operation reads through this path, one newer file blocks all auth profile I/O.

Source

Thrown at crates/zeroclaw-providers/src/auth/profiles.rs:430

        if bytes.is_empty() {
            return Ok(PersistedAuthProfiles::default());
        }

        let mut persisted: PersistedAuthProfiles =
            serde_json::from_slice(&bytes).with_context(|| {
                format!(
                    "Failed to parse auth profile store at {}",
                    self.path.display()
                )
            })?;

        if persisted.schema_version == 0 {
            persisted.schema_version = CURRENT_SCHEMA_VERSION;
        }

        if persisted.schema_version > CURRENT_SCHEMA_VERSION {
            anyhow::bail!(
                "Unsupported auth profile schema version {} (max supported: {})",
                persisted.schema_version,
                CURRENT_SCHEMA_VERSION
            );
        }

        Ok(persisted)
    }

    async fn write_persisted_locked(&self, persisted: &PersistedAuthProfiles) -> Result<()> {
        if let Some(parent) = self.path.parent() {
            fs::create_dir_all(parent).await.with_context(|| {
                format!(
                    "Failed to create auth profile directory at {}",
                    parent.display()
                )
            })?;
        }

View on GitHub (pinned to 88bb9c8533)

Solutions

  1. Upgrade the zeroclaw binary to at least the version that wrote the file
  2. Or move the file aside (e.g. `auth-profiles.json.bak`) and re-authenticate into a fresh store
  3. Do not hand-edit `schema_version` down — newer field layouts can silently lose or corrupt data
  4. Pin one zeroclaw version across machines that share the state directory
Defensive patterns

Strategy: validation

Validate before calling

let raw = tokio::fs::read_to_string(store.path()).await.unwrap_or_default();
if let Ok(v) = serde_json::from_str::<serde_json::Value>(&raw) {
    if v["schema_version"].as_u64().unwrap_or(1) > 1 {
        // written by a newer build: upgrade the binary or quarantine the file before store ops
    }
}

Try / catch

match store.load().await {
    Ok(d) => d,
    Err(e) if e.to_string().contains("schema version") => {
        return Err(anyhow!("auth store written by a newer zeroclaw; upgrade or remove {}", store.path().display()));
    }
    Err(e) => return Err(e),
}

Prevention

When it happens

Trigger: Opening a state directory written by a newer zeroclaw release (schema_version 2+) with an older binary; syncing or replicating the state dir between machines running different versions.

Common situations: Downgrading after trying a pre-release; CI using an older image against a home-dir volume produced by a newer local build; shared dotfiles managers pushing a newer store to an older host.

Related errors


AI-assisted analysis of zeroclaw-labs/zeroclaw@88bb9c8533 (2026-08-23). Data as JSON: /api/errors/08b4a8b62bd6e7d6. Report an issue: GitHub.