Conditional Breakpoint: Does Not Stop When Using A Private Variable

[ZianAtFirstWatch]

Prerequisites

• I have written a descriptive issue title.
• I have searched all open and closed issues to ensure it has not already been reported.
• I have read the troubleshooting guide.
• I am sure this issue is with the extension itself and does not reproduce in a standalone PowerShell instance.
• I have verified that I am using the latest version of Visual Studio Code and the PowerShell extension.
• If this is a security issue, I have read the security issue reporting guidance.

Summary

When the condition in a conditional breakpoint contains a reference to a private variable defined by the script, the breakpoint is not activated.

PowerShell Version

Name                           Value
----                           -----
PSVersion                      7.4.12
PSEdition                      Core
GitCommitId                    7.4.12
OS                             Microsoft Windows 10.0.20348
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0.}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visual Studio Code Version

1.105.1
x64

Extension Version

ms-vscode.powershell@2025.4.0

Steps to Reproduce

1. Launch VS Code with the PowerShell extension installed.
2. Paste the following code into a new window.

$numbers = 1..100

foreach ($private:number in $numbers) {
    write-host $private:number
    if ($private:number -eq 100) {
        write-warning "The breakpoint should trip before this line of code."
    }
}

3. Add a breakpoint to line 4.

4. Right-click on the breakpoint and click on "Edit Breakpoint..."

5. Enter the following expression.
   $private:number -eq 100

6. Run the script.

Visuals

No response

Logs

After setting the log level to Trace, I restarted VS Code and reproduced the issue. Afterwards, none of the folders in "%APPDATA%\Code\User\globalStorage\ms-vscode.powershell\logs" appeared to have been modified today.

This issue might be related to #5223. But that one uses "$_" instead of "$private:".