---
name: gh-api-leading-slash-msys-rewrite
description: "Under Git Bash, `gh api /repos/...` gets MSYS path-rewritten into a filesystem path and fails — the empty output reads as an absent row, not a failed fetch."
metadata: 
  node_type: memory
  type: reference
  originSessionId: eff1f397-bc60-464a-b7cf-b0a5b20a148d
  modified: 2026-08-03T03:15:01.522Z
---

On Windows Git Bash (the Bash tool on hfenduleam), `gh api "/repos/{o}/{r}/actions/jobs/{id}/logs"` fails with:

`invalid API endpoint: "C:/Program Files/Git/repos/..." Your shell might be rewriting URL paths as filesystem paths. To avoid this, omit the leading slash`

MSYS rewrites the leading-slash argument into a Windows path before `gh` ever sees it. Fixes: drop the leading slash (`gh api "repos/{o}/..."`), or use `gh run view --job <id> --log` for a completed run.

**Why it matters beyond the typo:** the failure writes a 1-line error INTO the output file, so a subsequent `grep` for the row you wanted returns zero matches and reads as "the row is absent" / "the test never ran". That is the [[zero-match-filter-reads-as-absent]] class arriving through a transport failure rather than a bad pattern. Check the fetched artifact's line count against a plausible floor before grepping it — a 3000-line job log that arrives as 1 line is the tell.

Complements [[gh-run-poll-jobs-not-status]] (mid-run job logs need the API at all) and [[render-not-read-pipefail]].