On Windows the configured shell was always executed as `cmd.exe /C <shell>`. That inserts a cmd.exe even for simple values like `command = wsl ~` or `command = pwsh -NoLogo`, producing two processes where one would do. Two concrete side effects: An extra cmd.exe appears in every Windows terminal's process tree (visible in Task Manager / process listings), two processes per surface where only one is the user's shell. cmd.exe state set by AutoRun (`HKCU\Software\Microsoft\Command Processor\AutoRun`, used commonly for DOSKEY aliases or `cd` in `init.cmd`) lives in the wrapping cmd process, not in the user's shell. Since AutoRun state like DOSKEY aliases is per-process, the user's aliases don't reach the shell they actually interact with. Run the shell value directly instead. If it contains whitespace, split on whitespace into argv. A bare `cmd.exe` is resolved via `%COMSPEC%` (the documented path to the current command processor). Other bare values are left to PATH resolution in `Command.startWindows` (#12387). The simple whitespace split does not honor Windows CLI quoting rules; users who need quoted arguments should use the direct command form, which takes an argv array as-is. For the common case (`wsl ~`, `pwsh -NoLogo`, `cmd.exe /k init.cmd`, etc.) this covers the shapes users actually write today. Also skips the termios focus timer on Windows in `focusGained`, since Windows has no termios -- the callback was arming a timer whose tick did nothing and just added noise. --- AI usage disclosure: developed with Claude Code (Claude Opus 4.7). Claude drafted the implementation based on my design direction -- I picked which pieces belong in this PR (drop the cmd wrapper, use `%COMSPEC%`, skip the termios focus timer) and which belong in sibling PRs. I reviewed each diff and validated it with a Windows GNU-ABI smoke build before pushing. Part of the Win32 apprt upstreaming series (see discussion #2563 / mattn/ghostty#1).