You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
pwsh: encodeEnvVarsForPowerShell rejects Windows-standard env var names like ProgramFiles(x86), breaking wsh token on every pwsh block #3481
encodeEnvVarsForPowerShell in pkg/util/shellutil/tokenswap.go validates every environment variable name against the strict POSIX-identifier regex ^[A-Za-z_][A-Za-z0-9_]*$ (IsValidEnvVarName in pkg/util/shellutil/shellquote.go), and this validation is applied unconditionally to ALL shells in EncodeEnvVarsForShell, including pwsh.
Windows always defines environment variables containing parentheses, e.g. ProgramFiles(x86) and CommonProgramFiles(x86). These names fail the regex, so encodeEnvVarsForPowerShell returns:
invalid env var name: "ProgramFiles(x86)"
EncodeEnvVarsForShell propagates this as a hard error, which aborts the entire token exchange, not just the one offending variable.
Why this matters
This is not a cosmetic edge case, it fires on essentially every PowerShell block launch on Windows. Wave's own bundled pwsh shell-integration script (wavepwsh.ps1, generated for the pwsh shell type) runs:
wsh token $env:WAVETERM_SWAPTOKEN pwsh 2>$null
The 2>$null silently swallows the error, so the failure is invisible in normal use, but the entire env-var/init-script exchange for that block never runs.
Root cause
$env:ProgramFiles(x86) = "..." is invalid PowerShell syntax (parens are parsed as a command invocation), so the strict validator was presumably written to avoid emitting that. But PowerShell has a second, valid assignment form for exactly this case:
${env:ProgramFiles(x86)}="..."
The ${env:NAME} delimited form tolerates parentheses (and most other characters) in the variable name. The validator doesn't need to reject these names for PowerShell at all, it just needs to emit the delimited form instead of the bare $env:NAME form.
Suggested fix
Scope the fix to encodeEnvVarsForPowerShell only (leave encodeEnvVarsForBash / encodeEnvVarsForFish untouched, the POSIX identifier rule is correct there):
Emit ${env:%s} = %s instead of $env:%s = %s.
Only reject a name if it's structurally impossible to express in that form (empty, or contains a literal }), rather than requiring a POSIX identifier.
Environment
Wave Terminal / wsh version: v0.14.5 (also present in current main as of this report, pkg/util/shellutil/tokenswap.go is unchanged on that path)
I can take this if it's still wanted. I verified the reported behavior against current main and the PowerShell encoder still applies the POSIX env-name validator before emitting $env:NAME. I'd keep the fix narrowly scoped to the PowerShell encoder, preserve bash/fish behavior, and add regression coverage for standard names plus ProgramFiles(x86) / CommonProgramFiles(x86). Happy to proceed if nobody is already working on it.
Activity
vortsghost2025 commentedon Sep 7, 2026
I can take this if it's still wanted. I verified the reported behavior against current
mainand the PowerShell encoder still applies the POSIX env-name validator before emitting$env:NAME. I'd keep the fix narrowly scoped to the PowerShell encoder, preserve bash/fish behavior, and add regression coverage for standard names plusProgramFiles(x86)/CommonProgramFiles(x86). Happy to proceed if nobody is already working on it.