ssh_execute fails on a Windows Server target ('timeout' is not recognized)

[melvynai]

I have a mix of Linux boxes and one Windows Server 2022 host running OpenSSH. The Linux
ones work fine, the Windows one fails on every command.

ssh_execute either hangs for about 30 seconds and gives up, or comes back with:

'timeout' is not recognized as an internal or external command

Plain ssh user@host from my terminal to the same box works, so the host itself is fine.
DEFAULT_DIR doesn't seem to have any effect on it either — commands seem to run from the
home directory whatever I set.

Is there something to configure for Windows targets, or is it just not supported?

[bvisible]

It's supported, there's just one setting you have to declare — and it can't be auto-detected, since there's no reliable way to know a remote host's OS before running something on it. So the default is Linux, and your Windows box is being treated as one.

Add this to the server:

SSH_SERVER_WINBOX_PLATFORM=windows

or platform = "windows" if you're using the TOML format.

That error message is the giveaway. For Linux targets commands get wrapped for timeout enforcement, roughly timeout <n> sh -c '<your command>' — and neither timeout nor sh exists on Windows OpenSSH, so your command never actually runs. Once platform is set, that wrapper is skipped and the SSH library's own timeout is used instead, which is also why you were seeing it give up around 30 seconds rather than at the timeout you asked for.

Same reason DEFAULT_DIR looked ignored: changing directory is cd <dir> && <cmd> on Linux, but Set-Location '<dir>'; <cmd> on Windows. With the wrong platform it's emitting shell syntax cmd.exe doesn't understand.

You can check it took with ssh_list_servers — the entry should show platform: "windows". If it shows nothing at all, the variable name is off, or the server isn't being picked up in the first place, which is a different problem.

Worth saying since it catches people the other way round too: platform describes the remote host, never the machine you're running from. If you're on Windows yourself connecting to Linux servers, leave it alone — setting it there would disable the wrapper those hosts actually need.

And if you're on an older release, upgrade first (npm i -g mcp-ssh-manager@latest). A handful of Windows issues were client-side bugs that are already fixed — startup crashes, false "dead" sessions, ssh_sync from a Windows host.

Also — two in one morning 🙂 If you've got more piled up, don't hold back, send them all at once. I'll do you a bulk discount.