Compatibility with Screen reader/Blind access (powershell disabled PSReadLine)

[kostiklv]

The issue we faced was wsl2-ssh-agent stopped working. I've spent quite a lot of time troubleshooting everything - reinstalling wsl2-ssh-agent, re-adding keys, even setting up a new distro in WSL with the clean setup but nothing helped, until I've noticed that when I'm starting Powershell from WSL, I see a notice:

Warning: PowerShell detected that you might be using a screen reader and has disabled PSReadLine for compatibility purposes. If you want to re-enable it, run 'Import-Module PSReadLine'.

It turned out that NVDA was installed on the PC, but then uninstalled. Apparently, it didn't clean up and left some registry values.

The problem is common. Here is an answer on MS forum about how the screen reader (or what Powershell thinks to be the screenreader) can be disabled: https://answers.microsoft.com/en-us/windows/forum/all/screen-reader-is-turned-on-how-can-i-disable-it/25610dbe-748b-478a-9743-d2e19534cc47
To fix that you need to run:

Set-ItemProperty -Path 'HKCU:\Control Panel\Accessibility\Blind Access' -Name On -Value 0

and then restart your PC.

Here is a discussion of another issue caused by the screenreader: PowerShell/PowerShell#11751

This is not wsl2-ssh-agent fault, and I'm not sure if it fails because of the unexpected warning when starting Powershell or actually because of disabled PSReadLine (haven't noticed any usage of it). If it's the former, I think the code could be modified to ignore the warning. If it's the latter, wsl2-ssh-agent could show a more meaningful error message. Currently, this how it looks:

./bin/wsl2-ssh-agent -foreground -verbose
[L] 2025/03/18 10:37:51 start listening on /home/user/.ssh/wsl2-ssh-agent.sock
[L] 2025/03/18 10:37:51 invoking [W] in PowerShell.exe
[L] 2025/03/18 10:37:51 PowerShell.exe does not respond in 3s
[L] 2025/03/18 10:37:51 invoking [W] in PowerShell.exe (trial 2/3)
[L] 2025/03/18 10:37:52 PowerShell.exe does not respond in 6s
[L] 2025/03/18 10:37:52 invoking [W] in PowerShell.exe (trial 3/3)
[L] 2025/03/18 10:37:52 PowerShell.exe does not respond in 10s
[L] 2025/03/18 10:37:52 shutdown
[L] 2025/03/18 10:37:52 failed to accept: accept unix /home/user/.ssh/wsl2-ssh-agent.sock: use of closed network connection

Another side effect of the issue is that when wsl2-ssh-agent fails, it creates an empty folder instead of the ssh-socket file. On the subsequent run (when the problem with PSReadLine is fixed) - wsl2-ssh-agent still fails, likely because it can't overwrite the empty folder.

P.S. I understand that it's not exactly wsl2-ssh-agent issue, but improving the handling or just output could help others facing a similar issue. At least they'll be able to find it here. Thanks!

[mame]

Thank you for your report.

I'm not sure if it fails because of the unexpected warning when starting Powershell or actually because of disabled PSReadLine

I'm not sure either. wsl2-ssh-agent starts PowerShell.exe and runs repeater.ps1, which outputs a signal byte when its startup is complete. When wsl2-ssh-agent detects this signal byte, it assumes that repeater.ps1 has been successfully invoked.

Unfortunately, wsl2-ssh-agent has no way of knowing what happens inside PowerShell.exe until repeater.ps1 starts successfully. The log you provided indicates that it retries because it didn't detect the expected signal byte within 3 seconds. This means wsl2-ssh-agent cannot determine what happens inside PowerShell.exe side, so it cannot provide a meaningful error message in the log.

The best I can suggest is adding a troubleshooting note: "Try launching PowerShell.exe from the WSL2 side and confirm that it starts successfully." Would that have helped in your case?

[kostiklv]

@mame , thanks for your prompt response.

Looks like repeater.go expects exactly 1 byte and it has to be 0xff and has to be the first. Maybe it could be modified to ignore everything until it gets the required byte? I'd probably even use a string like 'repeater.ps1 started' instead of the byte to avoid any ambiguity.

This is not ideal and a bit naive, but on the other hand, as long as PowerShell has started and you've got the output you were waiting for, you can probably just ignore anything PowerShell had to say before. The assumption is that if the errors/warnings are critical - it won't get to the point of doing the output of the magic byte/string.

It doesn't look like repeater.ps1 is using PSReadLine, so it should be the response parsing problem. The PowerShell does start successfully, it just shows a warning, but it starts just fine when you run /mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe

[mame]

Ah, I misread the log you provided. It looks like it didn’t actually wait 3 seconds. Maybe it did receive something other than \xff, as you said.

Maybe it could be modified to ignore everything until it gets the required byte?

That sounds like the right approach.

I'd probably even use a string like 'repeater.ps1 started' instead of the byte to avoid any ambiguity.

That would be better, but it seems like a hassle to implement in Go.

Could you write a patch?

[mame]

I think this is fixed by #17