I'm a big user of both RD Tabs (of course) and ConEmu, a great terminal app for Windows. I am not sure when this issue started, but it was not always present. I think in later Windows 10 builds something may have changed to cause this, but I don't have any evidence and I can't trace the behavior to anything in RD Tabs' source code (certainly the source code has not changed materially in a couple years).

So here's the issue. If you are connected to a remote desktop session where in that session you are running ConEmu, when you switch out of RD Tabs to another Window then back in, you'll see the "@" symbol appear in your ConEmu window one or more times. This happens consistently every time the focus changes back to that window.

Using a keylogger, I was able to see that every time the focus changes on the RDP control, it appears that it resets the keyboard state, sending 50 or more "key up" events for all modifier keys as well as a key-down key-up cycle for keycode 255. I don't have any code like this in RD Tabs. And just to be sure, I disabled all the input focus fix-ups in a debug build and it still happened. I think it's just a change in the underlying RDP control, at least the hosted control that RD Tabs uses. I don't see this behavior in the native app.

In a way it makes sense, there certainly was a problem in older versions of the control where keyboard modifiers could get stuck if you switched out of remote focus to another app then clicked back in. To the remote session, it would, for example, see a SHIFT KEY DOWN event, but not always a SHIFT KEY UP event. By just blanketing the remote session when focused is resumed with KEY UP for all modifiers, it prevents this issue from happening.

So that's all well and good, why does it impact ConEmu? I'm not entirely sure, but I think that keycode 255 may be the culprit since it's the only KEY DOWN event that appears in the input stream. But, again, I'm not sure.

In any case, it manifests as a "@" in the input stream. And there's nothing in RD Tabs I can do to fix this, I can't stop those key codes from going to the remote desktop.

But you can fix this with a little workaround in ConEmu! Basically you just need to assign an empty macro to the keycode it is receiving and it won't output anything anymore.

Go to the Keys & Macro section, select "Macros" in the drop-down. Find an empty macro. I just used Macro 32. Give the "Choose hotkey" field input focus, then click out of RD Tabs to another window and click back in. It will change from to just an empty field. Even though you don't see anything, it's been assigned to that weird rogue keypress. Click save and you are done.