If the prompt-string character that is turned red to signal parser errors is colored, the color isn't restored on resolving the error.

[mklement0]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues, especially the pinned issues.

Exception report

N/A

Screenshot

On resolving the parser error, > is printed with the default foreground color rather than in green:

Environment data

PS Version: 7.6.0-preview.3
PS HostName: ConsoleHost
PSReadLine Version: 2.3.6
PSReadLine EditMode: Emacs
OS: Darwin MacBook-Pro.local 24.4.0 Darwin Kernel Version 24.4.0: Fri Apr 11 18:33:47 PDT 2025; root:xnu-11417.101.15~117/RELEASE_ARM64_T6000 arm64
BufferWidth: 180
BufferHeight: 60

Steps to reproduce

Define the following prompt, which prints foo followed by a green > char. (and a space):

function prompt { "foo$($PsStyle.foreground.Green)>$($PSStyle.Reset) " }

Type a single quote character, which provokes a parser error and turns the > red.

Type a closing quote to resolve the parser error.

---

Presumably related:

• Error line indication faulty in multiline prompt PowerShell#21363 (should be transferred here)
• Using an emoji as the prompt text parse error replacement causes glitchy text to remain in the text buffer #3857

Expected behavior

On resolving the parser error, the > should be restored with its original color, i.e. green.

Actual behavior

On resolving the parser error, the > is restored with the default foreground color.

Note that using PSReadLine seemingly does recognize the > despite being surrounded by ANSI escape sequences, but makes no attempt to preserve its color.

Note that trying something like Set-PSReadLineOption -PromptText "$($PsStyle.foreground.Green)>$($PSStyle.Reset) " does not help - PSReadLine doesn't recognize it as part of the prompt string.