Summary
windows/Start-UltraCode.ps1 fails to run on Windows PowerShell 5.1 (the default powershell.exe that the Start menu / desktop .lnk launchers invoke). The launcher window flashes and closes immediately; nothing starts.
Root cause
Line 233 (as of de3a006) contains a literal em-dash — (U+2014):
Write-Host " (worker set explicitly — plain /model picks change orchestrator only)"
The file is saved as UTF-8 without a BOM. Windows PowerShell 5.1, when running a BOM-less script via -File, decodes it as the system ANSI code page (Windows-1252), not UTF-8. The em-dash is UTF-8 bytes E2 80 94; the third byte 0x94 is the right double-quotation mark " in CP1252. That byte prematurely terminates the string literal, so the rest of the line and the surrounding if/else block collapse into garbage tokens.
Result: 11 cascading parse errors, e.g.:
Start-UltraCode.ps1:233 char:97 Unexpected token ')' in expression or statement.
Start-UltraCode.ps1:232 char:34 Missing closing '}' in statement block or type definition.
Start-UltraCode.ps1:220 char:14 Missing closing '}' ...
Start-UltraCode.ps1:235 ... Unexpected token '"
Reproduce
# Windows PowerShell 5.1
[System.Management.Automation.Language.Parser]::ParseFile(
'...\windows\Start-UltraCode.ps1', [ref]$null, [ref]([ref]$errs).Value)
# -> 11 errors, all downstream of line 233
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\windows\Start-UltraCode.ps1 -Status
# -> dies with the parse errors above; exit 1
PowerShell 7+ (pwsh) defaults to UTF-8 and does not reproduce — which is likely why it slipped through. The desktop/Start-menu shortcuts use powershell.exe (5.1), so end users hit it.
Fix (one of)
- Simplest / recommended: replace the em-dash with ASCII
-- (the rest of the file already uses --). Keeps the script pure-ASCII and immune:
Write-Host " (worker set explicitly -- plain /model picks change orchestrator only)"
- Or save
Start-UltraCode.ps1 with a UTF-8 BOM so 5.1 decodes it correctly.
Option 1 is safer (no BOM, no encoding dependency). Suggest also adding a CI/pre-commit guard that rejects non-ASCII bytes in .ps1 launchers.
Environment
- Windows 11 Pro 26200, Windows PowerShell 5.1
- UltraCode-Shim @
de3a006 (current main)
Summary
windows/Start-UltraCode.ps1fails to run on Windows PowerShell 5.1 (the defaultpowershell.exethat the Start menu / desktop.lnklaunchers invoke). The launcher window flashes and closes immediately; nothing starts.Root cause
Line 233 (as of
de3a006) contains a literal em-dash—(U+2014):The file is saved as UTF-8 without a BOM. Windows PowerShell 5.1, when running a BOM-less script via
-File, decodes it as the system ANSI code page (Windows-1252), not UTF-8. The em-dash is UTF-8 bytesE2 80 94; the third byte0x94is the right double-quotation mark"in CP1252. That byte prematurely terminates the string literal, so the rest of the line and the surroundingif/elseblock collapse into garbage tokens.Result: 11 cascading parse errors, e.g.:
Reproduce
PowerShell 7+ (
pwsh) defaults to UTF-8 and does not reproduce — which is likely why it slipped through. The desktop/Start-menu shortcuts usepowershell.exe(5.1), so end users hit it.Fix (one of)
--(the rest of the file already uses--). Keeps the script pure-ASCII and immune:Start-UltraCode.ps1with a UTF-8 BOM so 5.1 decodes it correctly.Option 1 is safer (no BOM, no encoding dependency). Suggest also adding a CI/pre-commit guard that rejects non-ASCII bytes in
.ps1launchers.Environment
de3a006(currentmain)