fix: avoid bash backslash mangling of github.action_path on Windows (fixes #150)#298
Open
adityachilka1 wants to merge 1 commit into
Open
Conversation
…ows runners
The ${{ github.action_path }} template expression resolves to a backslash
path on Windows (D:\a\_actions\...\v0.1.14). When inlined into a bash run
block, bash treats backslashes as escape sequences, mangling the path.
Switching to the auto-injected $GITHUB_ACTION_PATH env var routes through
shell variable expansion, which preserves the literal value.
Fixes modelcontextprotocol#150.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #150.
The bug
When the action runs on a Windows runner,
${{ github.action_path }}resolves to a backslash-separated path like:GitHub Actions then inlines that string directly into the body of the
bashrun:block. Bash sees\a,\m,\c, etc. as escape sequences (or as ambiguous characters whose backslashes get consumed depending on the surrounding context), and the resulting path is mangled.That matches the symptom in #150 exactly — the error reports a lookup at:
The literal
\a,\_,\m, etc. were consumed during bash's processing of the inlined string, and the residue was treated as a relative path appended to the workflow's CWD (D:\a\webman-mcp\webman-mcp\).The fix
Replace the two
${{ github.action_path }}usages insidebashrun:blocks with the auto-injected$GITHUB_ACTION_PATHenvironment variable. GitHub Actions sets this variable on every composite-action step automatically. Because bash evaluates$GITHUB_ACTION_PATHas a variable expansion (not a template inlining), the value is treated as an opaque string — no escape processing on the backslashes.Two-line diff:
The
${{ inputs.* }}references elsewhere in the file are kept as-is — inputs are typed strings from the workflow and don't carry Windows path separators.Why this is the right fix (vs. alternatives)
sed 's|\\\\|/|g'— converts backslashes to forward slashes at runtime. Works on Windows bash, but adds a runtime step and obscures the cause.env: ACTION_PATH: ${{ github.action_path }}— explicit env block, also works. Equivalent to using$GITHUB_ACTION_PATHbut more verbose and duplicates what GHA already provides.$GITHUB_ACTION_PATHdirectly — minimal, idiomatic, matches what other composite actions in the ecosystem use (e.g.,actions/setup-node,pnpm/action-setup). Picked this.Verification
The fix can be verified by re-running the user's workflow at https://github.com/luoyue712/webman-mcp/actions/runs/22035652643 (linked in #150) with this action ref. Locally I confirmed the env-var form preserves Windows-style paths through bash variable expansion (no backslash consumption).
No behavioural change on Linux/macOS runners —
$GITHUB_ACTION_PATHresolves identically to${{ github.action_path }}on those platforms.