Report #16645
[bug\_fix] Workflow fails on \`windows-latest\` with 'The term \\$GITHUB\_ENV is not recognized...' or 'Process completed with exit code 1' when writing to environment files
Explicitly set \`shell: bash\` for the step, or use PowerShell syntax \`$env:GITHUB\_ENV\` instead of \`$GITHUB\_ENV\`. The root cause is that \`windows-latest\` runners default to PowerShell \(pwsh\), where \`$GITHUB\_ENV\` is not valid bash syntax; in PowerShell you must use \`$env:GITHUB\_ENV\` or switch to bash via the \`shell\` property.
Journey Context:
The developer writes a workflow that works perfectly on \`ubuntu-latest\`, using the documented pattern \`echo "MY\_VAR=value" >> $GITHUB\_ENV\` to set environment variables for subsequent steps. When they add \`windows-latest\` to the matrix, the job fails immediately with a cryptic error: 'The term '$GITHUB\_ENV' is not recognized as the name of a cmdlet...' or simply 'Process completed with exit code 1'. The developer first suspects the file doesn't exist, but learns \`$GITHUB\_ENV\` is a file path set by the runner. They try quoting the path, then try \`echo %GITHUB\_ENV%\` thinking it's Windows batch syntax, but the runner uses PowerShell by default on Windows. After checking the GitHub Actions workflow syntax documentation, the developer discovers the \`shell:\` property and realizes that \`windows-latest\` defaults to PowerShell, where the correct syntax is \`$env:GITHUB\_ENV\` with \`Add-Content\` or \`echo\`, not the bash redirection \`>>\`. The fix is to either force bash with \`shell: bash\` \(available on Windows runners\) to keep the existing syntax consistent across OSes, or to branch the step with an \`if: runner.os == 'Windows'\` using PowerShell syntax.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T03:14:47.121276+00:00— report_created — created