Short summary
GitHub Copilot App terminal integration on Windows with PowerShell 7 throws PSReadLine ValidateSet warnings
Affected version or release
GitHub Copilot App version: 1.0.90-0
Installation context
Windows 11, PowerShell 7 terminal inside GH Copilot App
What happened?
I’m using the GitHub Copilot App terminal integration on Windows with PowerShell 7.
When I open a PWSH 7 terminal “there” (inside GH Copilot App), the shell emits the following warning on startup:
Set-PSReadLineKeyHandler: \?\C:\Users\USERNAME\AppData\Local\Programs\GitHub Copilot\terminal-integration\shellIntegration.ps1:268:55
Line |
268 | … Set-PSReadLineKeyHandler -Chord $Sequence -Function $Handler.Function
| ~~~~~~~~~~~~~~~~~
| Cannot validate argument on parameter 'Function'. The argument "PSCompletionsMenuComplete" does not belong to the
| set
| "Abort,AcceptAndGetNext,AcceptLine,...,YankPop" specified by the ValidateSet attribute. Supply an argument that is in the set and then try the command again.
This warning is coming from the GitHub Copilot App’s bundled PowerShell shell integration script at:
C:\Users\USERNAME\AppData\Local\Programs\GitHub Copilot\terminal-integration\shellIntegration.ps1
The script maps the current PSReadLine keyhandler to VS Code/GitHub Copilot keybindings.
In my environment, Get-PSReadLineKeyHandler returns a handler whose Function value is PSCompletionsMenuComplete.
When the app then calls Set-PSReadLineKeyHandler -Function $Handler.Function, PowerShell rejects it because PSCompletionsMenuComplete is not a valid public PSReadLine function in the ValidateSet.
Actual behavior:
- The shell starts successfully, but the warning is printed every time a Copilot terminal is launched.
Steps to reproduce
Environment:
- Windows 11
- PowerShell 7
- GitHub Copilot App version: 1.0.90-0
Start Github Copilot App, open/toggle "Panel", click "Terminal" to open a Terminal pane/window.
Expected behavior
- The terminal integration should not emit a warning during shell startup.
- Private/internal completion function names should be normalized to a valid public handler or skipped safely.
Additional context
What I confirmed:
- Replacing
PSCompletionsMenuComplete with MenuComplete removes the warning without breaking the keybinding behavior.
This appears to be a GitHub Copilot App shell-integration bug, not a local PowerShell 7 or profile configuration issue.
If this is the right issue tracker, please route it to the terminal integration owner. Also, it likely mirrors the same pattern used in the upstream VS Code shell integration logic.
Short summary
GitHub Copilot App terminal integration on Windows with PowerShell 7 throws PSReadLine ValidateSet warnings
Affected version or release
GitHub Copilot App version: 1.0.90-0
Installation context
Windows 11, PowerShell 7 terminal inside GH Copilot App
What happened?
I’m using the GitHub Copilot App terminal integration on Windows with PowerShell 7.
When I open a PWSH 7 terminal “there” (inside GH Copilot App), the shell emits the following warning on startup:
This warning is coming from the GitHub Copilot App’s bundled PowerShell shell integration script at:
C:\Users\USERNAME\AppData\Local\Programs\GitHub Copilot\terminal-integration\shellIntegration.ps1The script maps the current
PSReadLinekeyhandler to VS Code/GitHub Copilot keybindings.In my environment,
Get-PSReadLineKeyHandlerreturns a handler whoseFunctionvalue isPSCompletionsMenuComplete.When the app then calls
Set-PSReadLineKeyHandler -Function $Handler.Function, PowerShell rejects it becausePSCompletionsMenuCompleteis not a valid public PSReadLine function in theValidateSet.Actual behavior:
Steps to reproduce
Environment:
Start Github Copilot App, open/toggle "Panel", click "Terminal" to open a Terminal pane/window.
Expected behavior
Additional context
What I confirmed:
PSCompletionsMenuCompletewithMenuCompleteremoves the warning without breaking the keybinding behavior.This appears to be a GitHub Copilot App shell-integration bug, not a local PowerShell 7 or profile configuration issue.
If this is the right issue tracker, please route it to the terminal integration owner. Also, it likely mirrors the same pattern used in the upstream VS Code shell integration logic.