jdx/mise · error

cmd.exe cannot use a UNC path as a working directory work

Error message

cmd.exe cannot use a UNC path as a working directory

  working directory: {dir}

It would start in C:\Windows instead and run the command there, so mise stops rather
than running it somewhere you did not ask for.

What it means

On Windows, when a task's cache command runs under cmd.exe, the working directory must be a real drive path: cmd.exe cannot start in a UNC path (\\server\share\...) and would instead start in C:\Windows, silently running the command elsewhere. mise detects this (cmd_shell_cannot_use_dir) and stops with this error instead of executing the command in an unexpected directory.

Source

Thrown at src/task/task_executor.rs:1438

        let mut inputs = Vec::with_capacity(cache.command_inputs.len());
        for command in &cache.command_inputs {
            if command.trim().is_empty() {
                eyre::bail!(
                    "task {} cache command input must not be empty: {command:?}",
                    task.name
                );
            }
            let (program, args, cmd_verbatim) =
                self.get_cmd_program_and_args(command, task, &[])?;
            // The same refusal as in `exec_program`, and it matters more here: these commands feed
            // the cache key, so running them from C:\Windows would hash the wrong directory's
            // answer. Measured on 2026.8.6 with the project on a UNC share — a `command_inputs`
            // entry reading a file that exists in the project fails, while the same config on a
            // local path succeeds. `--dry-run` does not reach here (see the cache branch in
            // `run_task`), so there is nothing to exempt.
            #[cfg(windows)]
            if cmd_shell_cannot_use_dir(&program, &root) {
                eyre::bail!("{}", unc_working_dir_error(&root));
            }
            #[cfg(not(windows))]
            let _ = cmd_verbatim;
            let program = program.to_executable();
            #[cfg(windows)]
            let program = crate::path::resolve_posix_shell_program_path(&program, &filtered_env)
                .unwrap_or(program);
            let runner = CmdLineRunner::new(program);
            #[cfg(windows)]
            let runner = if cmd_verbatim {
                args.iter().fold(runner, |runner, arg| runner.raw_arg(arg))
            } else {
                runner.args(&args)
            };
            #[cfg(not(windows))]
            let runner = runner.args(&args);
            let mut runner = runner
                .current_dir(&root)

View on GitHub (pinned to afd2eddd3a)

Solutions

  1. Map the UNC share to a drive letter (net use Z: \\server\share) and run the project from Z:\...
  2. Move/copy the project to a local drive (e.g. C:\src\proj)
  3. Change the task command so it doesn't run under cmd.exe (use pwsh, which supports UNC cwd) on Windows
  4. Use `subst` to alias a drive letter to the UNC path as a quick fix

Example fix

# before (cwd on UNC share, cmd.exe)
cd \\server\share\proj && mise run build
# after
net use Z: \\server\share
cd Z:\proj && mise run build
Defensive patterns

Strategy: validation

Validate before calling

import os
if os.name == "nt" and cwd.startswith("\\\\"):
    raise SystemExit("cmd.exe tasks need a drive-letter cwd; map the UNC share first")

Type guard

fn cmd_compatible_cwd(dir: &std::path::Path) -> bool {
    !cfg!(windows) || dir.to_str().map(|s| !s.starts_with("\\\\")).unwrap_or(true)
}

Try / catch

try {
  execSync("mise run build", { cwd: projectDir });
} catch (e) {
  if (String(e).includes("UNC path as a working directory")) {
    console.error("Map the share to a drive letter, e.g. net use Z: \\\\server\\share");
  }
  throw e;
}

Prevention

When it happens

Trigger: Running a task on Windows whose project/working root is a UNC path (\\server\share\proj or \\wsl$\...) while the cache command_input's program resolves to cmd.exe/cmd/%COMSPEC% — hit in the cache command-input path at task_executor.rs:1437.

Common situations: Source checked out on a network share; corporate environments without mapped drives; \\wsl$ interop paths; CI workspace on a UNC share with cmd as the shell.

Understand the failure class

Background: "unsupported platform" / "not supported on this platform" errors: what they mean and how to fix them — this error's family across 47 libraries.

Related errors

AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/a6c7dade5046e443. Report an issue: GitHub.