PowerShell keyboard input lost in remote sessions: PSReadLine

PowerShell keyboard input lost in remote sessions can occur on Windows Server 2022 accessed through Royal TSX, Remote Desktop Manager or the Parallels RAS HTML5 client. The window is active, but keystrokes never reach PowerShell.

The symptom

• The issue appears in a published desktop or RDP session.
• CMD accepts the keyboard while PowerShell stays silent.
• The same server works from a local console or another access path.
• The behaviour can be reproduced with Royal TSX, Remote Desktop Manager and, depending on the route, the RAS HTML5 client.

The likely cause

PowerShell 5.1 loads the PSReadLine module for interactive command-line editing. On some RDP or HTML5 input paths, an older PSReadLine build can mishandle keyboard events forwarded by the remote client. The symptom is misleading: PowerShell itself is running, but its interactive line reader is no longer receiving characters correctly.

The immediate workaround

From CMD or another console that still accepts input, start PowerShell and unload PSReadLine:

Remove-Module PSReadLine

PowerShell falls back to basic line input and keystrokes become available again. The command does not uninstall anything or make a permanent configuration change. It only affects the current session.

The durable fix

In the Windows Server 2022 case we investigated, the host reported PowerShell 5.1.20348.5622 and PSReadLine 2.0.0 loaded from:

C:\Program Files\WindowsPowerShell\Modules\PSReadLine\2.0.0\PSReadLine.psd1

After updating to PSReadLine 2.4.5, keyboard input worked again in the tested Royal TSX, Remote Desktop Manager and HTML5 sessions. Check the version that is actually available and loaded:

Get-Module PSReadLine -ListAvailable
Get-Module PSReadLine

Update the module on the machine where PowerShell runs inside the published session, using the normal change process for the environment. Test on a lab host first, then open a completely new remote session.

Why CMD still works

CMD does not use PSReadLine. It uses a different console and input loop. That is why CMD can accept the keyboard in the same session where PowerShell appears frozen. This is a useful isolation clue: RDP and the keyboard path may be healthy, while PowerShell’s interactive layer is the failing component.

Production checks

• Windows Server and PowerShell versions.
• The PSReadLine version actually loaded, not only the folders present on disk.
• Session type: classic RDP, RAS published desktop, HTML5 client or an intermediate gateway.
• Behaviour after fully closing and reopening the session.
• Policies or profiles that might load an older module again.

Takeaway

If PowerShell only loses keyboard input remotely, start with Remove-Module PSReadLine to regain control. If the issue returns, check the loaded version and replace PSReadLine 2.0.0 with a recent validated build, such as 2.4.5 in our lab. The behaviour depends on the session path, so it may never appear on a local console.

For more troubleshooting context, see the Parallels RAS logs guide and Microsoft’s Remove-Module reference.