fix: suppress ANSI escape sequences in PowerShell output via NO_COLOR#117
Conversation
Set NO_COLOR=1 in the subprocess environment so that pwsh 7.2+ disables ANSI formatting automatically. The variable is silently ignored by Windows PowerShell 5.1, which never emits ANSI sequences anyway, and is also respected by other CLI tools invoked inside the PowerShell session.
There was a problem hiding this comment.
Pull request overview
This PR reduces noisy ANSI escape sequences in captured PowerShell output by setting NO_COLOR=1 in the subprocess environment when spawning PowerShell, improving readability and reducing token usage in downstream consumption.
Changes:
- Set
NO_COLOR=1on the environment passed to the PowerShell subprocess inexecute_command.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
For certain window like vscode some of the ui elements name i usually get was [?] |
|
I've also noticed this issue with VS Code. I used Accessibility Insights for Windows to investigate and found that these UI elements contain an unidentified Unicode character \uEAB6. This is likely what's causing the [?] to appear. Perhaps we could remove this specific character from the output. 
|
|
yes may be regex filter works |
Summary
PowerShell 7.2+ (pwsh) can emit ANSI color escape sequences in its output (
\x1b[0m,\x1b[32;1m,\x1b[44;1m, ...), which makes the captured text harder to read and increase token consumption. This PR setsNO_COLOR=1in the subprocess environment so that pwsh 7.2+ disables ANSI formatting automatically, without touching the command string itself.Changes
src/windows_mcp/desktop/service.pyenv["NO_COLOR"] = "1"on the subprocess environment immediately afteros.environ.copy(), before the PowerShell process is spawned.Why
NO_COLOR