Bitvise SSH Client 9.5x Version History 
For issues that might arise using the latest SSH Client versions, see Known issues.
Changes in Bitvise SSH Client 9.56: [ 10 January 2026 ]
Graphical UI:
Dark mode: If the Windows color mode is set to Light or Custom; and the Windows app mode is set to Light; then list view headers, scrollbars and system menus would appear with light backgrounds instead of dark. Fixed.
Terminal window:
Implemented a compatibility improvement to allow the terminal window to work with Sogou Pinyin IME.
Improved Unicode handling for characters in the last column of the window.
Changes in Bitvise SSH Client 9.55: [ 1 January 2026 ]
Graphical SFTP:
In previous 9.5x versions, when using dark mode, the SFTP window would hang if file icons were not yet available in the Windows Explorer icon cache.
For the technically inclined: this is an interesting interaction between the Windows function SHGetFileInfoW, which is used to retrieve file icons; and the Windows List View control, if it's set to use a transparent background: LVS_EX_TRANSPARENTBKGND.
If a file icon is not yet cached by Windows, SHGetFileInfoW starts a nested message loop. This is so that the application can remain responsive during a potential extended adventure in search of the icon. In the case of the SSH Client, this nested message loop occurred in the middle of a List View paint cycle, because the List View requested an icon, and this is what caused the SSH Client to call SHGetFileInfoW. During the nested message loop, a new paint cycle is started, which is by design - maintaining UI responsiveness. Although List View is already in a paint cycle, the reentrant paint normally works, as long as the application has not set a transparent background. If it has, then the List View does not support reentrant paint with transparency, aborts the paint, and schedules a new paint. The new paint is scheduled in the nested message loop, which continues indefinitely until it's drained. This causes an infinite cycle of attempted and aborted paints between List View and SHGetFileInfoW, and SHGetFileInfoW never returns.
Microsoft appears to be aware of such issues: current documentation warns that calling SHGetFileInfoW on a UI thread may cause the UI to stop responding. The SSH Client got away with this for 20 years. With version 9.55, we are replacing this with a cache component which calls SHGetFileInfoW on a background thread. As a tradeoff, this causes uncached icons to appear slightly after the files are shown.
Suggestion to Microsoft: Since current documentation already recommends applications to avoid calling SHGetFileInfoW on a UI thread, remove the nested message loop functionality from SHGetFileInfoW. It seems to be an unexpected feature which attempts to solve one problem by introducing other problems. For example - besides infinite paint cycles, stack overflow seems possible if SHGetFileInfoW keeps being called from the nested message loop again.
Changes in Bitvise SSH Client 9.54: [ 22 December 2025 ]
Graphical terminal:
When rendering multiple characters at a time, the SSH Client now specifies the width of each character. This avoids cumulative misalignment if Windows chooses to render text using a wider font, in particular when using bold style.
Changes in Bitvise SSH Client 9.53: [ 18 December 2025 ]
General:
Improved consistency of window titles.
Graphical terminal:
Version 9.51 introduced section-based text rendering to accommodate font ligatures. This can cause problems if Unicode characters are included in a sequence that's rendered together. All Unicode characters outside of the ASCII range are now again rendered per-character.
As a consequence, text sequences such as Hebrew will once again render left-to-right, not right-to-left. This is necessary for cursor behavior to match what is displayed when editing text in the terminal.
The graphical terminal now supports Unicode non-spacing marks as long as they can be folded onto the preceding character. For example, the sequence "A" U+0302 U+0303 may now be rendered as the single character "Ẫ" (U+1EAA).
If non-spacing marks cannot be folded onto the preceding character, they are still rendered separately. For example, the partially invalid sequence "A" U+0303 U+0302 is now rendered as "Ã" (U+00C3), followed by a separate U+0302. Exact normalization behavior depends on the version of Windows.
Changes in Bitvise SSH Client 9.52: [ 15 December 2025 ]
Terminal:
In version 9.51, the terminal window in the graphical SSH Client was rendering Unicode characters incorrectly. Fixed.
General:
In version 9.51, the authentication dialog did not set input focus correctly. Fixed.
If a profile is opened, the window title for the main SSH Client window now also displays the profile name when not connected.
Changes in Bitvise SSH Client 9.51: [ 12 December 2025 ]
Automatic updates:
Separate proxy settings can now be configured for automatic updates. This allows checks for updates, and downloads of new version installers, to use a different proxy than the one configured in Windows.
SSH:
Bitvise SSH Server, SSH Client and FlowSsh now support hybrid post-quantum and classical key exchange using the key exchange methods mlkem1024nistp384-sha384 and mlkem768x25519-sha256. These key exchange methods use algorithms outside of Windows cryptography. They are only available when FIPS 140 cryptography mode is not enabled in Windows. The new algorithms require Windows Vista or newer.
The SSH Client can now be configured to Require strict key exchange. Strict key exchange is a recent SSH protocol feature supported since Bitvise software versions 9.32. It mitigates the Terrapin vulnerability in SSH implementations prior to December 2023 (CVE-2023-48795). If the SSH connection does not use strict key exchange, the encryption algorithm chacha20-poly1305 is particularly vulnerable.
Graphical SSH Client:
The SSH Client now supports dark mode. This can be enabled using the main SSH Client window > App settings.
When selecting a client authentication keypair, the SSH Client now displays a truncated comment. This makes it easier to tell which key is which.
App settings (previously, Window behavior) can now be controlled using command-line parameters. This is of particular interest for users who use -noRegistry.
Settings for pop-up notifications can now be configured using App settings, in addition to the icon menu in the system notification area.
The SSH Client now detects when another SSH Client instance is already connected to the same server, using the same username. This is to help users notice when they have an existing SSH Client instance hidden in the system notification area.
When importing a client authentication keypair, the SSH Client now more thoroughly detects duplicates.
Graphical SFTP:
Local and Remote SFTP settings are now configurable in separate dialogs. These settings can now be edited via the SFTP window.
Settings are now supported to express a preference whether the server should use unbuffered I/O. The preference is effective when connecting to Bitvise SSH Server 9.34 or newer, if server-side settings permit.
The sftpc command-line client supports the equivalent -noBuf switch for get and put commands since version 9.34.
When the remote directory contains symbolic links, the SSH Client must resolve them to know if an entry is a file or a directory. This requires an SFTP request for each symbolic link. For directories that contain many symbolic links which cannot be resolved, the SSH Client now gives up if it encounters 10 failures without any successes.
The feature to Open or Edit remote files uses a temporary local directory. If something removes this directory, the SSH Client now tries to re-create it.
Terminal window:
Font ligatures are now rendered, when using fonts that support them.
Command-line clients:
sftpc no longer reports an error if the server disconnects during the quit or exit command.
The sexec and stermc command-line clients now support consecutive execution of multiple commands using -cmdFile=... or using multiple -cmd=... parameters.
The sexec command-line client now supports an -inputEOL=... parameter to control how input newlines should be sent to the remote process. Default behavior remains to perform no conversion.
The sexec command-line client now supports a -conInMode=... parameter to control how input should be read from the console (when input is not redirected from a pipe or file). Default behavior is now to read individual keystrokes and send them promptly, without local echo.
The retry utility now supports -m=0 for infinite retries.
Port forwarding:
Bitvise SSH Client, stnlc and FlowSsh now support port forwarding (connection tunneling) to and from server-side Unix sockets. To use a Unix socket as the forwarding source or destination, enter the socket path (starting with "/") and leave the port empty.
This requires a server running on Linux or Unix. Only server-side Unix sockets are supported. The client side of the port forwarding must still use TCP/IP.
Known issues
Windows XP: All versions of our software that we recommend using are built using Visual Studio 2015. The C++ run-time library used by this Visual Studio version has a known issue where 1-2 kB of memory are leaked each time a new thread is created. This issue does not occur on later Windows versions; it does not occur e.g. on Windows Server 2003. Microsoft has stated they do not intend to fix this issue. Bitvise's view is that the impacts on our SSH Client and FlowSsh are manageable; whereas our SSH Server is rarely used on Windows XP. We therefore do not plan to work around this; but we warn that this can be a potential denial of service vector on Windows XP.
Older versions
Bitvise SSH Client 9.1x Version History
Bitvise SSH Client 8.xx Version History
Bitvise SSH Client 7.xx Version History
Bitvise SSH Client 6.xx Version History