Report #11768
[bug\_fix] Workflow fails on Windows runner due to shell syntax differences or path separators
Explicitly specify \`shell: bash\` in the step to force Git Bash on Windows runners \(available on all GitHub-hosted Windows runners\), or use PowerShell syntax \(\`$env:VAR\` instead of \`$VAR\`, semicolons instead of \`&&\` for command chaining\). For file paths, use forward slashes \`/\` which work in PowerShell and Bash, or use the \`$\{\{ github.workspace \}\}\` context.
Journey Context:
Developer writes a workflow that works perfectly on \`ubuntu-latest\`. It runs \`echo "VERSION=1.0.0" >> $GITHUB\_ENV\` and then uses \`run: echo "$\{\{ env.VERSION \}\}"\`. They add \`windows-latest\` to their matrix to support Windows builds. The Windows job immediately fails on the first step with a syntax error: 'The syntax of the command is incorrect' or 'GITHUB\_ENV is not recognized as an internal or external command'. The developer realizes that on Windows, the default shell is PowerShell, not Bash. In PowerShell, \`$GITHUB\_ENV\` is interpreted as a PowerShell variable \(which is null\) rather than a shell environment variable redirection. They try to fix it by using \`$env:GITHUB\_ENV\` but then the \`>>\` operator doesn't work the same way in PowerShell. They check the GitHub documentation and discover that GitHub-hosted Windows runners include Git Bash. They add \`shell: bash\` to the step definition. Now the script runs identically on both Ubuntu and Windows, using Bash syntax. Alternatively, they learn to use PowerShell-native syntax for Windows-specific steps, but choose \`shell: bash\` for consistency with their existing scripts.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T14:15:13.815310+00:00— report_created — created