sxyazi/yazi · critical
Failed to get state directory
Error message
Failed to get state directory
What it means
Windows branch of Xdg::load_state_dir: panics via expect when dirs::data_dir() — the Roaming AppData root (%APPDATA%) — returns None, so the "yazi\state" join cannot happen. yazi keeps persistent state (cursor position, tabs, plugin state) under this directory; it is resolved once per process at startup.
Source
Thrown at yazi-fs/src/xdg.rs:72
{
env::var_os("XDG_CACHE_HOME")
.map(PathBuf::from)
.filter(|p| p.is_absolute())
.map(|p| p.join("yazi"))
.or_else(|| dirs::home_dir().map(|h| h.join(".cache/yazi")))
.expect("Failed to get cache directory")
}
}
pub fn state_dir() -> &'static PathBuf {
static ONCE: OnceLock<PathBuf> = OnceLock::new();
ONCE.get_or_init(Self::load_state_dir)
}
fn load_state_dir() -> PathBuf {
#[cfg(windows)]
{
dirs::data_dir().map(|p| p.join("yazi\\state")).expect("Failed to get state directory")
}
#[cfg(unix)]
{
env::var_os("XDG_STATE_HOME")
.map(PathBuf::from)
.filter(|p| p.is_absolute())
.map(|p| p.join("yazi"))
.or_else(|| dirs::home_dir().map(|h| h.join(".local/state/yazi")))
.expect("Failed to get state directory")
}
}
pub fn runtime_dir() -> &'static PathBuf {
static ONCE: OnceLock<PathBuf> = OnceLock::new();
ONCE.get_or_init(Self::load_runtime_dir)
}
fn load_runtime_dir() -> PathBuf {View on GitHub (pinned to 94abcfa92f)
Solutions
- Restore a valid APPDATA for the account running yazi
- Use an interactive user profile, or wrap the launch so APPDATA is set
- Verify with `echo %APPDATA%` in the launching context
- If APPDATA cannot be restored, run yazi from a normal user session instead of the stripped context
Example fix
REM before: APPDATA unset -> panic "Failed to get state directory" set APPDATA=C:\Users\me\AppData\Roaming yazi.exe
Defensive patterns
Strategy: validation
Validate before calling
#[cfg(windows)]
fn state_dir_ok() -> bool {
std::env::var_os("APPDATA").is_some_and(|v| std::path::Path::new(&v).is_absolute())
} Prevention
- Set APPDATA in scheduled-task and service wrappers on Windows
- Avoid SYSTEM for yazi workloads; use a profile-backed account
- Check `echo %APPDATA%` before startup in the same context
When it happens
Trigger: First call to Xdg::state_dir() on Windows with APPDATA unset or unresolvable: SYSTEM/service accounts without a roaming profile, sanitized CI environments.
Common situations: Running yazi or ya as a scheduled task/service under SYSTEM; CI runners on Windows that strip APPDATA; group policies removing the roaming profile root.
Related errors
- Failed to get config directory
- Failed to get cache directory
- failed to get current working directory
- Time went backwards
- failed to spawn chafa: {e}
AI-assisted analysis of sxyazi/yazi@94abcfa92f (2026-08-16).
Data as JSON: /api/errors/748364828b0cd7ee.
Report an issue: GitHub.