Bug Report

Why will all this function keys get capture in a "remote desktop client" software? Remote Desktop Manager 2026.3.1.2 64-bit Runtime: .NET 10.0.13 Platform: Debian GNU/Linux 13 (trixie) Allocated memory: 284 MB

Hi, since the upgrade on the latest version SSH has a kind of annoying feature, it create a rename dialog for the connection while you are in an ssh session. Pretty sure nobody needs a short cut to rename a connection ever, even it's common shortcut in file explorers... can this be disabled or removed or if it can be configured point me where an disable it per default for other frustrated future users? Remote Desktop Manager 2026.3.1.2 64-bit Runtime: .NET 10.0.13 Platform: Debian GNU/Linux 13 (trixie) Allocated memory: 107 MB

Did anyone testing ssh before releasing new features? Open an SSH session and press ctrl+d to logout, instead the settings screen opens... who needs a shortcut for the settings screen? This version is so broken that I downgrade soon... Remote Desktop Manager 2026.3.1.2 64-bit Runtime: .NET 10.0.13 Platform: Debian GNU/Linux 13 (trixie) Allocated memory: 284 MB

In the latest version the new filter field is broken, when I filter for a connection, open the ssh connection and click back into the filter, I can't type anything. I can click on the X, which removes the content but clicking again in the field and try to type, it doesn't work. After alt+tab and going back it's working again. Remote Desktop Manager 2026.3.1.2 64-bit Runtime: .NET 10.0.13 Platform: Debian GNU/Linux 13 (trixie) Allocated memory: 327 MB

Hello Devolutions Support, Remote Desktop Manager for Linux terminates with SIGSEGV when I close an active SSH session. I have also observed a crash while leaving RDM running without interaction. Two captured crashes have the same native stack signature in g_object_remove_toggle_ref. The session-closing crash also occurred with X11 explicitly forced and the Wayland socket disabled for RDM. Impact The whole RDM process exits, interrupting my remote-session workflow. Environment - RDM version: 2026.3.1.1, x86_64 - Installation: system-wide Flatpak, origin "devolutions", branch "current" - App ID: com.devolutions.remotedesktopmanager - App ref: app/com.devolutions.remotedesktopmanager/x86_64/current - App commit: 6a30b972e332f8fb3b5f4f073da55ebbc1ffe85d2e26aa6ae973340b21f78235 - App build date: 2026-10-02 22:02:45 UTC - Desktop: KDE; session type: Wayland - Runtime: org.gnome.Platform/x86_64/49, origin "flathub", system installation - Runtime commit: 2bb946ea4ebb050f6a32f90e979feb975b08280d1ff1aac881dec3d1361ad84d - Runtime build subject: Build of the GNOME Runtime from: 49.10-1-g75d7cf116 - Runtime build date: 2026-10-03 06:00:39 UTC - libgobject/libglib reported in the crash: 2.86.5 (libgobject-2.0.so.0.8600.5) - NVIDIA library present in the first core: libnvidia-glcore.so.615.71.09 - Host distribution, kernel, Flatpak version and KDE version: not yet collected Steps observed to trigger the crash 1. Launch RDM. 2. Open and use an SSH session in RDM. 3. Close the active SSH session. 4. RDM can terminate with SIGSEGV instead of only closing the session. Expected: The SSH session closes and RDM remains running. Actual: The entire RDM process crashes and systemd records a core dump. Frequency: Observed more than once, but not established to happen on every session closure. An additional idle crash was observed. I have not established whether this began with the October 2 update. Crash evidence Both cores identify this executable: /app/lib/devolutions/RemoteDesktopManager/RemoteDesktopManager First captured crash: 2026-10-07 14:14:33 CEST, host PID 26701, SIGSEGV. Its symbolized native stack begins: #0 g_type_check_instance_is_fundamentally_a (...) at ../gobject/gtype.c:3917 #1 g_object_remove_toggle_ref (object=0x55798d1c8360, ...) at ../gobject/gobject.c:4561 #2 0x00007f336174438f in ??? () Second captured crash: 2026-10-07 15:32:00 CEST, host PID 32109, SIGSEGV, on closing an active SSH session during the forced-X11 test. Its symbolized native stack begins: #0 g_type_check_instance_is_fundamentally_a (type_instance=0x56015b1aba30, fundamental_type=0x50 [GObject]) at ../gobject/gtype.c:3917 #1 g_object_remove_toggle_ref (object=0x56015b1aba30, notify=0x7f27fbc19b90, data=0x7f17a1c145b0) at ../gobject/gobject.c:4561 #2 0x00007f27ff713f7f in ??? () #3 0x00007f185acae7a0 in ??? () #4 0x0000000000000001 in ??? () #5 0x00007ffd332abad0 in ??? () #6 0x0000000000000000 in ??? () The faulting source line reported by GDB in both cases is: node = lookup_type_node_I (type_instance->g_class->g_type); The managed caller is not resolved by these native GDB traces. An invalid or already freed GObject is a hypothesis, not a confirmed root cause. Troubleshooting completed - Installed the GNOME 49 SDK and debug symbols to inspect the cores. - Disabled GDB debuginfod retrieval and successfully obtained backtraces. - Tested this launch command: flatpak run --socket=x11 --nosocket=wayland --env=GDK_BACKEND=x11 com.devolutions.remotedesktopmanager - RDM still crashed when closing an active SSH session under that launch configuration, with the same native stack signature. - Queried the Devolutions remote using flatpak remote-info --system --log devolutions com.devolutions.remotedesktopmanager//current. It returned an empty History section, so no application rollback was tested. - No native .deb/.rpm installation or runtime rollback has been tested. Additional terminal messages during the forced-X11 run (RemoteDesktopManager:2): Gtk-WARNING **: 14:30:37.594: Locale not supported by C library. Using the fallback 'C' locale. (RemoteDesktopManager:2): GLib-GObject-CRITICAL **: 14:30:53.233: ../gobject/gsignal.c:2437: signal 'response' is invalid for instance '0x7f17a80089b0' of type 'GtkWindow' That warning occurred earlier in the run; a causal relationship with the later crash has not been established. Flatpak also reported reserved /etc certificate paths not being shared. GDB reported unavailable file-backed mappings and deleted memfd mappings, but successfully loaded the cores and resolved the two GObject frames. Available diagnostic files - rdm-backtrace.txt: first core, bt full and all-thread backtraces - rdm-32109-backtrace.txt: second core, top 15 frames requested - rdm-x11-test.txt: terminal output from the forced-X11 run Please confirm whether this is a known RDM/GTK binding object-lifetime issue or a GNOME 49 runtime compatibility issue. Is there a fixed build or recommended workaround? If a managed stack trace is required, please provide the appropriate SOS/runtime-symbol collection steps for this exact Flatpak build.

I just upgraded to 2026.3.0.5 64-bit and have since not been able to use the Special key as it brings up my host OS's Application Menu. It used to be that I could press Right Ctrl to toggle between the host OS and remote RDP session if this occurred but that is not working. I ran through various options in the application and wasn't able to find anything to address this. Standard keyboard input is fine, but even combinations like Alt+Tab are kept on the local host OS. Your team has been pretty awesome in continuing to develop this software on Linux so I hope this is a helpful bug report!

Dear Support Team, Thank you for your excellent product. I am already using it on Windows and now I am trying to use it on Ubuntu Linux as a replacement for Remmina. I would like to report a very small bug. It is not a major issue, but it can be a little annoying for non-English users who need to type accented characters in their daily work. Product: Remote Desktop Manager for Linux Version: 2026.3.1.1 64-bit, .NET 10.0.12 OS: Ubuntu 26.04.1 LTS, Wayland session [GNOME ?] Keyboard: Swiss French QWERTZ physical keyboard, layout "French (Switzerland)" Description In an embedded RDP session, dead keys are not taken into account. Pressing a dead key followed by a letter outputs only the letter, without the accent: ^ then e gives "e", not "ê". Pressing a dead key followed by Space outputs only a space, not the accent character itself. The dead key press itself produces nothing, so it is impossible to type ^, ~ or ¨ [exact key combination to confirm], or any accented letter built with them. This affects every dead key I tested: ^, ~ (AltGr + ^) and ¨ [to confirm]. Regular keys and other modified characters work normally: Shift + 2 gives ", AltGr + 2 gives @. Expected behavior The dead key is forwarded or composed correctly, so that ^ then e gives "ê", and ^ then Space gives "^", as with other RDP clients. What works Dead keys work normally in RDM's own interface (e.g. the search bar), including ^ then e giving "ê". With the same server, the same user and the same keyboard layout, both xfreerdp and wlfreerdp handle dead keys correctly and give "ê". What I tried without success RDP entry keyboard layout set to French (Switzerland) and to French (France) "Send Unicode" set to true and to false Launching RDM with GTK_IM_MODULE set to ibus and to none [and the AVALONIA_IM_MODULE / XMODIFIERS variants] Steps to reproduce Open an RDP session to a Windows machine from RDM on Ubuntu (Wayland), with a Swiss French keyboard. Click in a text field in the remote session (e.g. Notepad). Press ^, then e: only "e" appears. Press ^, then Space: only a space appears. Repeat with ~ (AltGr + ^) and ¨: same result. Analysis The dead key event seems to be lost between the local keyboard handling and the RDP layer on Wayland: the following key arrives as a plain key without any accent. This is my interpretation, not a confirmed diagnosis. I can provide logs or run additional tests if needed. Thanks in advance for your attention.

SUMMARY When an embedded RDP session tab is closed in Remote Desktop Manager for Linux, RDM does not close the TCP connection to the server. The socket stays ESTABLISHED and RDM stops reading it. The server therefore never sees a disconnect: the session remains "Active". A few minutes later every process in that session stops running until the session is really disconnected. For us this pauses a 24/7 application that runs in the interactive session on the server. ENVIRONMENT - Remote Desktop Manager for Linux 2026.3.0.5 (deb, amd64) - Ubuntu 24.04.5 LTS, GNOME on Wayland, kernel 7.0.0-28-generic - Session type: RDP, display mode: Embedded (tabbed) - Server: Windows Server 2016 Standard (10.0.14393), direct connection to port 3389, no gateway - Version 2025.3.0.8 was installed until 25 Sep 2026; we suspect the same behaviour there (similar incidents, not measured) STEPS TO REPRODUCE 1. Open an RDP session to a Windows server in an embedded tab and log on. 2. Close the tab (do not log off, do not use Start > Disconnect). 3. On the client: ss -tnpi '( dport = :3389 )' 4. On the server, from another session: quser ACTUAL RESULT Client: - The socket is still owned by RemoteDesktopManager and stays in ESTAB. - Recv-Q only grows, so RDM no longer reads it. One connection sampled after the tab was closed: Recv-Q 0 -> 2322 -> 2475 -> 2577 -> 2730 -> ... -> 5025 -> 7983 -> 8136, state ESTAB all the time. - When the server side is disconnected later, the socket goes to CLOSE-WAIT and stays there: RDM never closes its end. Server: - quser keeps showing the session as Active, not Disc. No disconnect is logged. - 2 to 4.5 minutes after the tab was closed (2:00, about 2:30, 3:25 and 4:27 in four runs; in a fifth run nothing happened within 5:47) all processes of that session stop: their CPU time no longer increases, GUI and console processes alike. About every 2 minutes they run for a moment and stop again. Processes in session 0 are not affected. - It also happens in a freshly created session. - The stall ends within a second when the session is really disconnected: "tsdiscon <id>" from another session, or the "time limit for active but idle sessions" policy, or a reconnect. The same processes simply continue. EXPECTED RESULT Closing the tab disconnects the RDP session and closes the TCP connection, as closing the window of mstsc or xfreerdp does. The server then shows the session as Disc. IMPACT After an administrator closes an RDM tab, the application running in that server session is frozen for minutes, until somebody reconnects. On servers where that application must run around the clock this is an outage. WORKAROUNDS WE USE - Start > Disconnect inside the session before closing the tab. - Server side: the idle-session limit policy, which disconnects the stuck session after the limit. QUESTIONS 1. Is this a known issue in RDM for Linux? 2. Is closing an embedded RDP tab meant to disconnect the session and close the socket? 3. Is there a setting that influences this? 4. Which logs would help? We can provide full "ss -tnpi" snapshots over time, the server-side session events, and RDM logs if you tell us how to enable the relevant ones.

CTRL+a d shortcut for session detaching (in 'screen' app) opens rdm machine properties instead of detaching the screen in terminal (in ssh session) it doesn't work in rdm-2026.3.1.1 it works in rdm-2026.2.2.2 ----- RDM installed on Debian 13.7

Hello, when pressing Ctrl+D to exit the terminal, in this version it suddenly started to open a duplicate session dialog instead of logging off the ssh session. Tested on Linux MInt 22.3 and Fedora 44.

Hello, In Remote Desktop Manager for Linux, clicking Open on a remote file downloads it successfully, but no editor opens and no error is displayed. Environment: RDM 2026.3.1.1, 64-bit, DEB installation Ubuntu 26.04.1 LTS GNOME / Wayland Default PHP file editor: VS Code Steps to reproduce: Connect to a Linux server over SSH and open the SFTP pane. Navigate to a file such as /home/ubuntu/example/config/Config.php. Right-click the file and select Open . The file is downloaded to: /tmp/RDM/edit_<hash>/Config.php However, the debug log reports the following (paths anonymized): OpenEdit - Failed to find file at location: /tmp/RDM/edit_<hash>//home/ubuntu/example/config/Config.php It appears that the full remote path is appended to the temporary directory where only the filename should be appended. Additional checks: Opening a local PHP file with xdg-open successfully launches VS Code. An execve trace showed no editor or xdg-open process being launched during the failed Open action. Creating a temporary directory symlink so the incorrect path resolves to the downloaded file made Open work immediately. Automatic upload after editing has not been tested. Updating from 2026.3.0.5 to 2026.3.1.1 fixed the separate issue where the SFTP pane would not open from the SSH toolbar, but this file-opening issue remains. Could you investigate the local path construction in the SFTP Open action?

Hi, I am having a scaling issue with Remote Desktop Manager for Linux 2026.2.0.4 on Ubuntu 26.04 / GNOME Wayland . The remote session content itself is readable, for example SSH terminal text is fine, but the RDM interface around it is extremely small: top menus; toolbar icons; filter bar; small UI controls. This makes RDM difficult to use on my setup. Environment Ubuntu 26.04 GNOME Wayland session Remote Desktop Manager 2026.2.0.4 5-monitor HiDPI / mixed scaling setup RDM version: apt policy remotedesktopmanager remotedesktopmanager: Installed: 2026.2.0.4 Candidate: 2026.2.0.4 Monitor layout: Monitors: 5 0: +*HDMI-4 6144/700x3456/390+2160+2880 HDMI-4 1: +DP-5 2160/600x3840/340+8304+2880 DP-5 2: +DP-6 2160/600x3840/340+0+2880 DP-6 3: +DVI-D-1 3840/600x2160/340+7280+720 DVI-D-1 4: +HDMI-5 5120/610x2880/350+2160+0 HDMI-5 RDM process environment: XDG_SESSION_TYPE=wayland WAYLAND_DISPLAY=wayland-0 DISPLAY=:0 GDK_BACKEND=x11 XAUTHORITY=/run/user/1000/.mutter-Xwaylandauth... So RDM appears to run under XWayland , while the desktop session is Wayland. What I tried I already tried the following without success: AVALONIA_GLOBAL_SCALE_FACTOR=1.5 remotedesktopmanager AVALONIA_GLOBAL_SCALE_FACTOR=2 remotedesktopmanager AVALONIA_GLOBAL_SCALE_FACTOR=4 remotedesktopmanager Also tried per-monitor scaling: AVALONIA_SCREEN_SCALE_FACTORS='HDMI-4=1.5;DP-5=1.5;DP-6=1.5;DVI-D-1=1.5;HDMI-5=1.5' remotedesktopmanager and also with scale factor 4. The variable is visible inside the RDM process environment, but it has no visible effect. I also tried: printf 'Xft.dpi: 144\n' | xrdb -merge printf 'Xft.dpi: 192\n' | xrdb -merge No effect. I tested with a clean RDM profile by moving ~/.rdm, but even the initial setup wizard starts extremely small, so it does not seem to be caused by my profile or saved layout. I also tried gamescope. It can make the whole window larger, but it causes mouse/input and resize issues, so it is not usable as a real workaround. Strange behavior A couple of times RDM seemed to start with normal scaling by itself, but I could not reproduce why. Most of the time it starts with the UI extremely small. This makes me suspect a DPI/scaling detection issue related to XWayland, monitor ordering, startup timing or initial window placement. Questions Is this a known issue with RDM Linux 2026.2.0.4 on Wayland/XWayland with HiDPI/fractional scaling? Is there an official way to force RDM UI scaling on Linux? Does RDM read any specific config file, command line option or environment variable for UI scaling? Thanks.

Hi, I prefer to open RDP Sessions in undocked mode. However, when configure the Undocked mode to be the default in the settings I'm missing the tabs on the window. This makes it also impossible to group the connections in undocked mode. Tested on version 2026.3.1.1 Best regards, Christoph Fink

Hi all, Firt issue: Since the last update, switching between shells while working on multiple simultaneous SSH sessions takes two seconds . Second issue: I constantly use Ctrl+D to close the session (which is the standard behavior on Linux), but the function has been changed; now, it edits the active connection instead. Would it be possible to restore the previous behavior? Thanks again.

Environment OS: Fedora Linux 44 Desktop environment: KDE Plasma Remote Desktop Manager: 2026.3.0.5 Connection type: SSH Remote host: Linux RDM terminal: built-in SSH terminal While using an SSH session in RDM, the terminal works normally for some time and then suddenly starts behaving as if the Alt/Meta key is still pressed . Normal keyboard input is replaced by sequences such as: ^[i ^[n ^[d ^[j ^[s ^[kFor example, typing normal characters results in ESC + character being sent to the remote shell. At the same time, Ctrl+C stops working correctly . The remote shell continues to behave abnormally and pressing Ctrl+C does not interrupt the current input/process as expected. Workaround Pressing the Alt key once immediately restores normal keyboard input. After pressing Alt, the SSH terminal works normally again without reconnecting the session. Reproduction / observed behavior Open an SSH session in RDM. Use the terminal normally. After some time, the keyboard input may become corrupted. The terminal starts receiving ESC + character sequences (^[x). Ctrl+C no longer works correctly. Pressing Alt once immediately fixes the problem. This seems to indicate that RDM is incorrectly retaining or restoring the Alt/Meta modifier state in the SSH terminal. Please investigate whether this is a regression or a known issue in the 2026.3.x terminal/keyboard handling on Linux.

Hi, the Update from 2026.2.2.2 to 2026.3.0.5 introduced a strange bug. Im Using Kubuntu 24.04. LTS with EN_US locale but DE_DE keyboard layount and a keyboard with german alyout. After the update to 3.0.5 my keypresses are not submitted correctly to an RDP connection. It seems they are submitted with the rdpmanager thinking I'm using EN_US keyboard layout. Downgrading to 2026.2.2.2 fixed the problem.

The option "Display the connection bar when in full screen mode" (Connection Properties -> General -> Display) doesn't seem to do anything at the moment. I expected that unchecking it would turn the connection bar off entirely when viewing a connection in full screen, but the connection bar is showing the same way independent of what this option is set to. The connection bar is probably quite useful depending on how someone uses remote desktops, but for me personally I really only use the close button and there are other ways to close the connection, so it's more in the way then being useful for me and it would be perfect if this option would function as it sounds like it's intended to do, so that I can disable the connection bar entirely for a connection.

After upgrading RDM from 2026.2.2.2 to 2026.3.0.5, two problems appeared inside remote desktop sessions: • Pressing the Spanish acute-accent key followed by a produces a instead of á. • Each mouse-wheel notch scrolls approximately 10 lines, much farther than before. Environment: CachyOS Linux, KDE Plasma on Wayland, RDM installed through the AUR package remote-desktop-manager. Both the local keyboard and RDM are configured for Spanish. Steps to reproduce on the affected setup: 1. Upgrade RDM from 2026.2.2.2 to 2026.3.0.5 and open an RDP session. 2. In a text field in the remote session, press the acute-accent key followed by a. 3. In a scrollable remote application, turn the mouse wheel one notch at a time. Expected: á is entered, and scrolling moves the normal amount per notch. Actual: only a is entered, and scrolling moves approximately 10 lines per notch. Downgrading only RDM to 2026.2.2.2 resolved both problems, without changing connection settings or downgrading system dependencies. The package versions were 2026.2.2.2-2 (working) and 2026.3.0.5-1 (affected). Comparing the packages showed Avalonia changed from 11.3.17 to 12.1.2, while the bundled libDevolutionsRdp.so was byte-for-byte identical. This may help narrow the investigation, although it does not establish the root cause. Please let me know whether this is a known regression and which release will contain a fix.

Product: Remote Desktop Manager (Linux), RDP connections via bundled FreeRDP. Note: an earlier forum reply (Simon Duguay Létourneau, https://forum.devolutions.net/topics/9648/wrong-keyboard-layout) stated RDM bundles FreeRDP 3.11.0 - we've since confirmed the actual version shipped is 3.16.0, so that reply may be outdated. Setup: RDM runs inside a browser-based Linux desktop (KasmVNC/KDE Plasma), German ("de") keyboard layout configured both client- and server-side, RDP connection's Keyboard Layout explicitly set to German (0x00000407). ### Symptom - With "Send as Unicode" enabled: pressing AltGr+ß (backslash on a German layout) inserts a garbage/incorrect character immediately before the backslash. - With "Send as Unicode" disabled: pressing AltGr alone is interpreted as "@" instead of being recognized as a modifier. - The RDP connection's Advanced tab no longer has a "Disable sandboxing" option (present in RDM ~2 years ago per the forum thread above), so that earlier troubleshooting step is no longer available to test. ### Root cause we were able to trace Our browser-based desktop's VNC layer (KasmVNC) delivers the physical AltGr key as X11 keycode 92 (a dynamically-allocated "spare" keycode) instead of keycode 108 (the standard position for AltGr on a German XKB layout) - confirmed via xev. We could not get KasmVNC to deliver the correct/expected keycode without breaking AltGr composition entirely (a separate, unresolved upstream VNC-side limitation we're pursuing with the KasmVNC project directly). Given that, it looks like FreeRDP's internal X11-keycode-to-VK table doesn't recognize keycode 92 as any known key, resulting in VK_NONE, and falls back to transmitting the composed character via Unicode input instead of a proper AltGr-modified keypress - which is what produces both symptoms above. ### Ask Since the incoming X11 keycode from the display server can genuinely vary (not every VNC/X setup delivers AltGr on the "textbook" keycode), could the AltGr/Level3 handling be made more robust to non-standard keycodes - e.g. by trusting the keysym (ISO_Level3_Shift) directly when the keycode lookup fails, rather than only falling back to a raw Unicode character transmission?

I've encountered another issue (I can open a separate case if necessary). I can't use any keyboard shortcuts, particularly the ones for executing predefined commands, macros, or scripts in an SSH session. [image]

Linux Kubuntu 24.04 , RDM 2026.3.0.5 64-bit In this version, sorting for folders based on "Sort Priority" does not work. In the screenshot, folders 1-2 have priority 0, while folder 3 has priority 10. For the connection list, sorting works correctly — server-3 with priority 10 is placed first. [image]

I see a few other topics about this, but keypresses are definitely broken for me. I think I figured out what triggers it, along with a workaround. It's annoying for sure, and it's not just RDP. I'm seeing the same thing with SSH connections too. I grabbed a video showing it, I just don't want to upload it here publicly. Basically, I connect and everything works fine. Then I switch to another app for a little while and come back to RDM. Boom, keyboard input is broken. I can't type anything. The up and down arrows sort of work, but not really. The workaround I've found is to click on another connection in the RDM connection list. It doesn't even need to actually be connected. Then I click back to the session I was using, and keyboard input starts working again. Super annoying. This only started happening for me with the latest version. Remote Desktop Manager 2026.3.0.5 64-bit Platform: CachyOS (KDE)

Hi, Zorin OS here. I have this behavior when I open several tabs with distinct SSH sessions and when I try to type special characters like ' or ", i cannot see what iḿ typing in the active tab but when i switch to another tab, those characters were written there. Regards

Hi, in RDM version 2026.3.0.5 on Linux with Gnome on Wayland the setting Application - Application Startup - Startup window state "minimized" "to the system tray" doesn't work right. When RDM is started, the system tray icon appears and after a few seconds, also the application window comes up. I tried "To the system tray", "To the taskbar" and "Both" with no difference in regards of the application window coming up instead of being minimized. Great work guys, RDM as improved a lot with the new surface. Best regards Markus

Version 2026.3.0.5 via normal deb package. Since update to this version my keyboard shortcut for Reconnect (CTRL+R) is no longer working. When connection to host is active this shrotcut does "(reverse-i-search)`':" on host instead of reconnect. When host is disconnected nothing is happening. Another thing with duplicating tab. I have 5 tabs opened. 4 saved and 1 opened via this field on the bottom (all ssh). Duplicating saved tab works ok. Duplicating this not saved tab works but it works differently. It creates new tab, activates last active tab, then asks for username, password. New duplicated tab is not activated (as it is when saved tab is duplicated). Clicking on SFTP button while connected to linux host via ssh does nothing.