Somebody on r/powershell described it like this: they built a Win32 Intune package, and right after that their PowerShell window started completing things on every keystroke. clear bought them a few seconds of calm, then it came straight back. Only closing the window and opening a fresh one actually held.
I've run into this before. If I remember correctly, the package is almost never the culprit. It's PSReadLine......
What PSReadLine actually is
PSReadLine is the module that owns your interactive line editor. It isn't the shell and it isn't your terminal app. Every time you type at a PS> prompt, PSReadLine is what draws the line and decides what happens when you press Tab. It ships with Windows PowerShell 5.1 and PowerShell 7+, so it's always there whether you installed it or not.
Since PSReadLine 2.2.6, one of its features is on by default: predictive IntelliSense. That's the thing drawing ghost text ahead of your cursor and guessing your next command from history or from a plugin.
Version 2.1.0 introduced the feature in 2020, but with PredictionSource set to None. 2.2.6 flipped the default on for any terminal that supports virtual terminal sequences, which is roughly every terminal you'd be using today.
With PredictionViewStyle left at its default of InlineView, the guess gets drawn into the line you're typing, ahead of the cursor. Nothing is accepted, no Tab is pressed, but the line keeps redrawing every time the guess changes. That's the "it's typing for me" feeling. Switch to ListView and you also get a drop-down grid under the line, which is what makes some setups unusable.
Look before you change anything
Run these two and read three things: the version, PredictionSource, and PredictionViewStyle.
Get-PSReadLineOption | Select-Object PredictionSource, PredictionViewStyle
Get-Module PSReadLine | Select-Object Version, Path
If PredictionSource says History or Plugin and you never asked for predictions, you found it. Check the version too. Windows PowerShell 5.1 historically shipped PSReadLine 2.0.0, and a profile that imports a different copy can give you behaviour the docs don't describe. Worth listing what's installed side by side:
Get-Module PSReadLine -ListAvailable | Select-Object Version, Path
Turning it off
To stop it outright:
Set-PSReadLineOption -PredictionSource None
If you like history hints and just don't want the ghost text moving around on you, keep predictions and force the inline view:
Set-PSReadLineOption -PredictionSource History
Set-PSReadLineOption -PredictionViewStyle InlineView
Either way that only applies to the session you ran it in. Microsoft is explicit about it: to persist any of these options, they have to go in a profile script.
notepad $PROFILE
# add the line you want, e.g.
# Set-PSReadLineOption -PredictionSource None
If $PROFILE doesn't exist yet, create it first with New-Item -Path $PROFILE -ItemType File -Force. Otherwise you'll edit an empty nothing and wonder why nothing changed. Been there.
The second cause, which looks identical
There's an uglier variant with the same symptoms. PSReadLine caches where your line starts in the console buffer, along with the starting column. When the terminal gets resized, or the buffer is narrowed and then widened again, that anchor isn't always recalculated. From then on, every keystroke re-renders in the wrong column. That's the chaotic version where the line jumps around and you can't type at all.
Upstream PR #5190 spells it out: the edit anchor is never restored for the rest of that ReadLine call.
This is also why clear feels like a fix. Clear-Host wipes the visible display and leaves your session state alone, so the badly aligned drawing disappears. The bad anchor doesn't. Next keystroke, back to the mess.
For this class, clear the display, or resize the window once and press Enter for a fresh prompt, then update the module:
Update-Module PSReadLine -Force
You'll want a new shell after that.
Two isolation checks
If none of the above changes anything, PSReadLine probably isn't the problem, and something else is setting it. Start a shell without your profile:
pwsh -NoProfile
If typing is normal there, a profile script or another module is doing it. From there it's also worth trying the same session in Windows Terminal and in the old conhost window, since host-specific rendering bugs exist and they don't behave the same in both.
The honest caveats
The thread I pulled this from had zero replies and no accepted answer, so I can't tell you which of the two mechanisms hit that person. The Intune theory in the post doesn't hold up either. IntuneWinAppUtil.exe packs a folder into an .intunewin container. It doesn't read or write PSReadLine state, $PROFILE, or $PSModulePath. It could only matter indirectly, if a packaging script itself ran Set-PSReadLineOption or wrote a profile, and there's no evidence of that in the thread.
Treat the Intune angle as unproven. Treat "PSReadLine is drawing ghost text, or drawing in the wrong column" as the thing to check first. Both are documented upstream and both are fixable in about a minute.
Worth a try. Hope it helps.
Top comments (0)