You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Prefer Windows OpenSSH when resolving a bare ssh shell spec #193
On Windows, a bare ssh user@host shell spec can resolve through PATH before the native Windows OpenSSH installation is considered. If Git or another package contributes an ssh.exe earlier on PATH, wmux can spawn that client even when the matching Windows ssh.exe and scp.exe pair is installed.
Why this matters
The selected client may not match the Windows OpenSSH behavior wmux expects.
Features that need the matching scp.exe cannot safely infer it from an unrelated PATH client.
A normal Windows installation should use %ProgramFiles%\OpenSSH when both tools exist, then %SystemRoot%\System32\OpenSSH, before falling back to PATH.
Expected behavior
Resolution order for a bare SSH spec should be:
An explicitly requested executable path.
A complete OpenSSH pair under Program Files.
Windows System32 OpenSSH.
The normal PATH fallback.
The behavior should be covered by Windows-focused unit tests.
Resolution order for a bare SSH spec is now exactly what you laid out: an explicit executable path, then a complete ssh.exe/scp.exe pair under %ProgramFiles%\OpenSSH, then %SystemRoot%\System32\OpenSSH, then PATH.
Worth recording the concrete failure mode this fixes, because it is nastier than "the wrong client got picked". Git for Windows usually puts usr\bin ahead of System32 on PATH, and its MSYS2 ssh looks for an agent on $SSH_AUTH_SOCK — while the Windows agent that 1Password, KeePassXC and the ssh-agent service all register with is the named pipe \.\pipe\openssh-ssh-agent. On a machine whose keys live only in an agent, wmux ssh user@host died on Permission denied (publickey) while the user's own ssh in the same pane worked fine. The two clients aren't interchangeable, they authenticate against different worlds.
The scope is narrow on purpose: this only touches shell specs wmux spawns itself (wmux ssh, a workspace shell set to ssh …). A command you type at a prompt is resolved by the shell inside the PTY and never goes through this path, so panes still behave like any other terminal.
Activity
LevSky22 commentedon Aug 24, 2026
Implementation: #196. The direct-SSH upload work tracked in #195 / #198 depends on deterministic Windows OpenSSH selection.
amirlehmam commentedon Aug 24, 2026
Fixed in #196, shipping in v1.12.0.
Resolution order for a bare SSH spec is now exactly what you laid out: an explicit executable path, then a complete
ssh.exe/scp.exepair under%ProgramFiles%\OpenSSH, then%SystemRoot%\System32\OpenSSH, then PATH.Worth recording the concrete failure mode this fixes, because it is nastier than "the wrong client got picked". Git for Windows usually puts
usr\binahead of System32 on PATH, and its MSYS2sshlooks for an agent on$SSH_AUTH_SOCK— while the Windows agent that 1Password, KeePassXC and the ssh-agent service all register with is the named pipe\.\pipe\openssh-ssh-agent. On a machine whose keys live only in an agent,wmux ssh user@hostdied onPermission denied (publickey)while the user's ownsshin the same pane worked fine. The two clients aren't interchangeable, they authenticate against different worlds.The scope is narrow on purpose: this only touches shell specs wmux spawns itself (
wmux ssh, a workspace shell set tossh …). A command you type at a prompt is resolved by the shell inside the PTY and never goes through this path, so panes still behave like any other terminal.amirlehmam commentedon Aug 24, 2026
Released: v1.12.0 — installer and portable zip are both up, and the installer path auto-updates.