fix(terminal): silence ShellExecute dialog when launching Windows Terminal

[JWM0203]

Summary

Fixes a long-standing bug where picking Windows Terminal as the preferred terminal causes a modal dialog Windows 找不到文件 'wt' to pop up on every launch, even though the existing fallback to cmd is supposed to handle the failure silently.

Root cause

launch_windows_terminal and the Windows branch of launch_terminal_running both invoke:

run_windows_start_command(&["wt", "cmd", "/K", &bat_path], "Windows Terminal")

which expands to cmd /C start wt cmd /K <bat>. When start cannot resolve wt, it routes through ShellExecute, which first pops a modal "Windows cannot find" dialog and only then returns failure. By the time the existing result.is_err() cmd-fallback fires, the user has already seen the popup.

This commonly hits users who run cc-switch elevated: an admin-elevated process inherits the SYSTEM PATH, which lacks the per-user %LOCALAPPDATA%\Microsoft\WindowsApps directory where wt.exe lives — so even though wt is installed, start wt can't find it.

Fix

Resolve a concrete path to wt.exe before invoking start:

1. Try where wt (covers the normal case).
2. Fall back to an explicit probe of %LOCALAPPDATA%\Microsoft\WindowsApps\wt.exe (covers the elevated-launch scenario).
3. If neither resolves, return Err(...) so the existing cmd fallback path kicks in cleanly — no modal dialog.

When wt.exe is found, pass the full resolved path to start (with an empty title argument: start "" "<full path>" cmd /K <bat>). ShellExecute against a concrete path doesn't show the "cannot find" dialog.

The change is minimal and contained: one new helper resolve_windows_terminal_path() plus a two-line replacement at each of the two existing Windows launch sites.

Test plan

• Built locally with pnpm tauri build --no-bundle on Windows 11 Pro 23H2 (MSVC 14.44, rustc 1.95.0)
• Reproduced the bug with the released v3.14.1 binary: dialog shows on every Provider launch when wt is the preferred terminal
• Verified the patched binary launches Windows Terminal cleanly with no dialog under both normal and elevated launch contexts
• Verified cmd and PowerShell selections continue to work unchanged
• No new warnings introduced; existing warnings in this file are pre-existing

[farion1231]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b6e6a994fa

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Use Windows encoding when reading where wt output

resolve_windows_terminal_path() decodes cmd /C where wt output with String::from_utf8_lossy, but cmd pipe output is not guaranteed to be UTF-8 (it follows the active Windows code page unless /U is used). If the resolved path contains non-ASCII characters (for example, localized profile names under %LOCALAPPDATA%), the decoded path becomes corrupted, start cannot launch wt.exe, and the app falls back to cmd even though Windows Terminal is actually present.

Useful? React with 👍 / 👎.