PSReadline history file is encrypted?

Maybe not encrypted, but bytes at the very least.
I’m familiar with the PSReadline history file and have explored mine before. Sometime last year I updated my PSReadlinemodule to 2.2.6 on my primary work Windows machine.
My PSReadline history has been working fine and my prediction source has been set to “History” for a long time.
I looked at my Console_history.txt file today in Notepad and found that it was filled with bytes rather than plain text. e.g.


It was actually much bigger, but I have since tried deleting it and establishing new history.
I use two different accounts on this machine and from what I can see they have identical PSreadlineoptions set, but only this one account has a history file like this. The same account on other computers, with the default PSReadline 2.0.0, has a plaintext history file.

I cannot seem to find any explanation for this behavior on the forum, the internet, or even going through PSReadline’s github issues.

Does anyone have an explanation for this behavior?

EDIT: as an experiment I read the console_history.txt file in as bytes, skipped the first two and converted it to Base64, then converted that Base64 string to plain text and voila, my history. But I still can’t find anything in PSReadline’s documentation that describes storing the command history in raw bytes.

Just curious. If you load the same file in VsCode, what does the encoding show?

Opening the console_history.txt file in VSCode and Notepad++ shows the encoding at UTF-16 LE.
It’s UTF-8 on my other user’s file.

What is the output from

[console]::OutputEncoding
PS> [console]::OutputEncoding


IsSingleByte      : True
BodyName          : IBM437
EncodingName      : OEM United States
HeaderName        : IBM437
WebName           : IBM437
WindowsCodePage   : 1252
IsBrowserDisplay  : False
IsBrowserSave     : False
IsMailNewsDisplay : False
IsMailNewsSave    : False
EncoderFallback   : System.Text.InternalEncoderBestFitFallback
DecoderFallback   : System.Text.InternalDecoderBestFitFallback
IsReadOnly        : False
CodePage          : 437

EDIT: as a test I renamed the 2.2.6 folder for PSReadline to “bak_2.2.6” to force Powershell to use the default 2.0.0 version. Re-opened Powershell, typed some commands and checked the Console_history.txt file and they’re still getting written in the same format.

Do you use any kind of custom font in your terminal?

Also maybe check your default encoding is output of…

[System.Text.Encoding]::Default.EncodingName

Mine is UTF-8

I’m primarily using Windows Terminal, though I also use VS Code.
In Windows Terminal I’m using “Hack Nerd Font”, but I am using the same setup for both of my accounts, and only one account’s Console_history.txt is exhibiting this behavior.

The functionality of PSReadline’s history still works. Meaning with my prediction source set to “History” I still get predictive text, so somehow PSReadline is reading this console history file without a problem


Compared to my other user account, also through Windows terminal

mine comes back as “Western European (Windows)”
If i open Pwsh 7.4.6 in Windows Terminal it is UTF-8, but it’s also reading/writing to console_history as bytes instead of plaintext, and that’s using the newer PSReadline v2.3.5

Ok, update on my end.
I finally just completely deleted my Console_history.txt file and relaunched Powershell and now my history file is in plain text.
I’m gonna go crazy wondering what caused this.
EDIT: I want to say it was @tonyd remark about the encoding on the file. If it was marked as UTF-16 encoding, maybe PSreadline was still reading/writing to it no problem, but when I try to view it I was seeing the bytes like the above picture. I kept a copy of the previous history file, and if I manually read it in as bytes, and immediately pass those to UTF8.GetString() it comes out as plain text. I think somewhere along the lines the file encoding got messed up.

So … I am going to guess that somehow, it was encoded as Unicode. Try this with the GOOD file.

Get-Content .\ConsoleHost_history.txt -Encoding Unicode

I get your Kanji garbage when I do this. I suspect if you did this with the “bad” file, it would be readable.

1 Like

good call.
Copying you on my GOOD file it absolutely looks like the same Kanji garbage when i read it as Unicode. It doesn’t unfortunately work on the bad file, but I think you’re on to the catalyst for this.