8000 Prefer Windows OpenSSH when resolving a bare ssh shell spec · Issue #193 · amirlehmam/wmux · GitHub
[go: up one dir, main page]

Skip to content

Prefer Windows OpenSSH when resolving a bare ssh shell spec #193

Closed

Description

@LevSky22

Summary

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:

  1. An explicitly requested executable path.
  2. A complete OpenSSH pair under Program Files.
  3. Windows System32 OpenSSH.
  4. The normal PATH fallback.

The behavior should be covered by Windows-focused unit tests.

Activity

  1. LevSky22 commented on Aug 24, 2026

    @LevSky22
    ContributorAuthor

    Implementation: #196. The direct-SSH upload work tracked in #195 / #198 depends on deterministic Windows OpenSSH selection.

  2. amirlehmam commented on Aug 24, 2026

    @amirlehmam
    Owner

    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.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.

  3. amirlehmam commented on Aug 24, 2026

    @amirlehmam
    Owner

    Released: v1.12.0 — installer and portable zip are both up, and the installer path auto-updates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      0