Windows: Terminal panel uses \\?\ extended-length path prefix, breaking cmd.exe child processes (npm, npx, etc.)

[matthewdonsemail-lab]

Description

The terminal panel in Berd spawns PowerShell with the session's working_dir set to the repository path. When the path is under C:\Users\... (or any long path), PowerShell resolves it to the Win32 extended-length path format \\?\C:\Users\.... This breaks any child process that spawns cmd.exe — including npm, npx, and many Node.js toolchains.

Symptoms

1. Terminal prompt shows the extended-length path format:

   PS Microsoft.PowerShell.Core\FileSystem::\\?\C:\Users\0\.buzz\REPOS\inferencesaver>
   

2. Running npm run dev (or any npm/npx command) fails with:

   '\\?\C:\Users\0\.buzz\REPOS\inferencesaver'
   CMD.EXE was started with the above path as the current directory.
   UNC paths are not supported.  Defaulting to Windows directory.
   

3. next dev crashes with:

   Error: EISDIR: illegal operation on a directory, lstat 'C:'
   

4. npm run dev:docs fails with:

   Could not read package.json: Error: ENOENT: no such file or directory, open 'C:\Windows\package.json'
   

Root Cause

• Berd's terminal panel spawns PowerShell with the session's working_dir as the initial CWD
• When the working directory is a normal Windows path like C:\Users\0\.buzz\REPOS\inferencesaver, PowerShell's FileSystem provider resolves it to the extended-length path format \\?\C:\Users\...
• cmd.exe (spawned by npm/npx) does not support \\? UNC paths as a CWD and falls back to C:\Windows
• This causes all downstream Node.js processes to fail because they're running from the wrong directory
• Even Git Bash (C:\Program Files\Git\bin\bash.exe --login) spawned from this terminal inherits the \\? CWD environment

Workaround

Run cd C:\Users\0\.buzz\REPOS\inferencesaver once in the terminal to reset the PowerShell provider path to the normal format. This is not obvious and wastes time every time a new terminal is opened.

Affected Environment

• Berd version: v0.6.2
• OS: Windows 10 (build 26100)
• Shell: PowerShell 5.1 (default Windows PowerShell)
• Node.js: v24.18.1

Suggested Fix

When spawning the terminal, Berd should normalize the working_dir path to its non-extended-length form (C:\... instead of \\?\C:\...) before passing it to PowerShell. This could be done by:

1. Passing the path without the \\? prefix when spawning the shell process
2. Or, if using PowerShell, prepending a cd to the non-extended path in the initial command
3. Or, using Git Bash or Windows Terminal as an alternative shell option

Impact

This is a significant UX issue for any Windows user of Berd who works with Node.js projects, Python projects, or any toolchain that spawns cmd.exe subprocesses. It makes the terminal unusable out of the box for running dev servers, builds, and package managers.

[matthewdonsemail-lab]

Root cause located in source

The terminal is spawned in src-tauri/src/commands/terminal.rs.

1. The \\?\ prefix comes from normalize_path():

fn resolve_terminal_cwd(cwd: &str) -> Result<PathBuf, String> {
    // ...
    Ok(normalize_path(&path))
}

fn normalize_path(path: &Path) -> PathBuf {
    path.canonicalize().unwrap_or_else(|_| path.to_path_buf())
}

On Windows, std::fs::canonicalize() returns the path in Win32 extended-length form (\\?\C:\...). That resolved path is then passed straight into process.cwd(&cwd) in start_terminal(), so the spawned PowerShell starts in \\?\C:\.... Any child that spawns cmd.exe (npm, npx, etc.) rejects that CWD and falls back to C:\Windows.

2. The shell is hardcoded with no user override:

fn resolve_shell(shell_env: &HashMap<String, String>) -> String {
    if cfg!(target_os = "windows") {
        // Windows PowerShell 5.1 is present on supported Windows versions.
        // Use the explicit executable name rather than `%ComSpec%`, which
        // intentionally points at cmd.exe.
        return "powershell.exe".to_string();
    }
    // ... POSIX: uses $SHELL
}

On Windows the shell is always powershell.exe — there is no setting to choose Git Bash, cmd, Windows Terminal, or any other shell.

Suggested enhancement: configurable terminal shell in Settings

In addition to fixing the path normalization (e.g. strip the \\? prefix or skip canonicalize() on Windows), add a Settings option for the terminal shell command/path so Windows users can set their preferred terminal (e.g. C:\Program Files\Git\bin\bash.exe, cmd.exe, wt.exe). The setting would feed into resolve_shell() and would both:

1. Let users pick a shell that handles the working directory correctly (most Git Bash/Windows Terminal setups do)
2. Give a natural workaround for this bug without waiting for a fix

Suggested UI: a "Terminal shell" text field under Settings → Terminal (or Advanced), defaulting to the current powershell.exe behavior, platform-specific (only shown on Windows where there is a real choice).