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
- 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
- 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
- Never pre-create the credentials path manually
- After backups or migrations, verify the path is a directory before logging in
- Delete wrong-shaped leftovers instead of renaming them into place
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
- Codewhale credentials directory cannot be a volume root
- refusing to replace an existing xAI OAuth generation
- invalid Codewhale-owned xAI OAuth basename
- xAI OAuth private basename must be one UTF-8 path component
- xAI OAuth credentials directory must be absolute
AI-assisted analysis of Hmbown/CodeWhale@8880682c63 (2026-08-16).
Data as JSON: /api/errors/09a1b3b511430a85.
Report an issue: GitHub.