Hmbown/CodeWhale · error

Codewhale-owned xAI OAuth path has the wrong filesystem type

Error message

Codewhale-owned xAI OAuth path has the wrong filesystem type

What it means

After the reparse check, validate_windows_handle_path verifies the handle's filesystem type against expectation: directory components (expect_directory=true) must be directories and credential files must be regular files. It catches wrong-shaped entries created by leftover files or scripts pre-creating paths.

Source

Thrown at crates/config/src/xai_credentials.rs:1213

    use std::os::windows::ffi::OsStringExt as _;
    use std::os::windows::fs::MetadataExt as _;
    use std::os::windows::io::AsRawHandle as _;
    use windows_sys::Win32::Storage::FileSystem::{
        FILE_ATTRIBUTE_REPARSE_POINT, FILE_NAME_NORMALIZED, GetFinalPathNameByHandleW,
        VOLUME_NAME_DOS,
    };

    let metadata = file.metadata().with_context(|| {
        format!(
            "inspecting Codewhale-owned path {}",
            crate::quote_os_path(expected)
        )
    })?;
    anyhow::ensure!(
        metadata.file_attributes() & FILE_ATTRIBUTE_REPARSE_POINT == 0,
        "Codewhale-owned xAI OAuth path must not be a reparse point"
    );
    anyhow::ensure!(
        if expect_directory {
            metadata.is_dir()
        } else {
            metadata.is_file()
        },
        "Codewhale-owned xAI OAuth path has the wrong filesystem type"
    );
    let flags = FILE_NAME_NORMALIZED | VOLUME_NAME_DOS;
    let handle = file.as_raw_handle();
    // SAFETY: null output asks only for the required UTF-16 length.
    let needed = unsafe { GetFinalPathNameByHandleW(handle, std::ptr::null_mut(), 0, flags) };
    if needed == 0 {
        return Err(std::io::Error::last_os_error())
            .context("resolving Codewhale-owned xAI OAuth handle path");
    }
    let mut buffer = vec![0u16; needed as usize + 1];
    // SAFETY: the buffer is writable and the handle remains valid.
    let written = unsafe {

View on GitHub (pinned to 8880682c63)

Solutions

  1. Check what the path really is (Get-Item / fsutil), then remove the wrong-typed entry and re-run codewhale auth xai-device so the store recreates it correctly
  2. Do not pre-create $CODEWHALE_HOME/credentials manually

Example fix

# before (PowerShell)
Get-Item "$env:USERPROFILE\.codewhale\credentials"   # a file, not a directory

# after
Remove-Item "$env:USERPROFILE\.codewhale\credentials"
codewhale auth xai-device   # store recreates it as a directory
Defensive patterns

Strategy: validation

Validate before calling

match std::fs::metadata(&dir) {
    Ok(m) if m.is_dir() => Ok(()),
    Ok(_) => anyhow::bail!("{} exists but is not a directory", dir.display()),
    Err(e) if e.kind() == std::io::ErrorKind::NotFound => Ok(()),
    Err(e) => Err(e.into()),
}

Prevention

When it happens

Trigger: $CODEWHALE_HOME/credentials exists as a regular file: fs::create_dir hits AlreadyExists, the later handle opens the file with BACKUP_SEMANTICS, and is_dir() is false; or a generation name (xai-auth-...json) exists as a directory.

Common situations: A leftover empty file named `credentials` from older tooling or a manual touch; scripts pre-creating the wrong path shape.

Related errors


AI-assisted analysis of Hmbown/CodeWhale@8880682c63 (2026-08-16). Data as JSON: /api/errors/09a1b3b511430a85. Report an issue: GitHub.