The summary below reflects a recurring error experienced on a remote development environment (ssh).
My CLI versions:
gh aw version v0.57.2
- gh version 2.88.1 (2026-03-12)
The error report is written by Copilot as a I am not familiar with the codebase - I did try to guide it. The described errors match the ones I observed and initially inquired about.
Summary
gh aw logs fails with a misleading error:
✗ GitHub CLI authentication required. Run 'gh auth login' first
…even though the user is fully authenticated (confirmed via gh auth status). The actual problem is that gh-aw requests a path JSON field from gh run list --json that does not exist in the GitHub CLI.
Root Cause
There are two bugs:
Bug 1: path is not a valid gh run list --json field
In listWorkflowRunsWithPagination, the command requests:
args := []string{"run", "list", "--json", "databaseId,number,url,status,conclusion,workflowName,path,createdAt,startedAt,updatedAt,event,headBranch,headSha,displayTitle"}
However, the gh CLI's RunFields has never included path. The valid fields are:
name, displayTitle, headBranch, headSha, createdAt, updatedAt, startedAt,
attempt, status, conclusion, event, number, databaseId, workflowDatabaseId,
workflowName, url
This causes gh to output:
🔍 Unknown JSON field: "path"
Notably, a regression test comment in logs_github_api_test.go acknowledges a prior issue with this field:
// Regression: commit 61cc2d7ac (Jan 4 2026) silently dropped "path" from the
// gh run list --json field list, causing WorkflowPath to always be "" and the
// .lock.yml filter in fetchWorkflowRuns to discard every run.
This suggests path was intentionally re-added to the gh-aw field list to fix a filtering regression — but the field was never actually supported by the gh CLI. It may have worked in some environments where gh silently ignored unknown fields, but it fails in environments where gh rejects them.
Bug 2: Error misclassification (case-sensitive string matching + overly broad heuristic)
The error handling in listWorkflowRunsWithPagination checks for invalid field errors before auth errors, which is correct in principle:
if strings.Contains(combinedMsg, "invalid field") ||
strings.Contains(combinedMsg, "unknown field") ||
strings.Contains(combinedMsg, "field not found") ||
strings.Contains(combinedMsg, "no such field") {
return nil, 0, fmt.Errorf("invalid field in JSON query ...")
}
However, the gh CLI outputs "Unknown JSON field" (capital U), and strings.Contains is case-sensitive in Go. So "unknown field" does not match "Unknown JSON field", and the check is skipped.
The code then falls through to the auth error check:
if strings.Contains(combinedMsg, "exit status 4") ||
strings.Contains(combinedMsg, "exit status 1") ||
...
The "exit status 1" heuristic matches because gh run list exits with code 1 on the invalid field error, so the user sees a completely wrong "authentication required" message.
Steps to Reproduce
- Use any standard version of the GitHub CLI (
gh).
- Run
gh aw logs -vvv.
- Observe:
- The verbose output shows
🔍 Unknown JSON field: "path"
- But the final error says
✗ GitHub CLI authentication required. Run 'gh auth login' first
gh auth status confirms you are authenticated.
Expected Behavior
gh-aw should not request JSON fields that the gh CLI does not support.
- If an unsupported field is requested and rejected, the error message should clearly indicate the incompatibility (e.g., "Unsupported JSON field 'path'. You may need to upgrade your gh CLI.") rather than claiming an authentication failure.
Proposed Fix
- Remove
path from the gh run list --json field list (or replace it with an alternative approach to get the workflow file path, such as using the REST API or workflowDatabaseId).
- Make error substring checks case-insensitive (e.g., use
strings.Contains(strings.ToLower(combinedMsg), "unknown field")).
- Narrow the
"exit status 1" heuristic — this is too broad and catches non-auth errors. Consider removing it or only matching when combined with auth-specific keywords.
References
The summary below reflects a recurring error experienced on a remote development environment (ssh).
My CLI versions:
gh aw version v0.57.2The error report is written by Copilot as a I am not familiar with the codebase - I did try to guide it. The described errors match the ones I observed and initially inquired about.
Summary
gh aw logsfails with a misleading error:…even though the user is fully authenticated (confirmed via
gh auth status). The actual problem is thatgh-awrequests apathJSON field fromgh run list --jsonthat does not exist in the GitHub CLI.Root Cause
There are two bugs:
Bug 1:
pathis not a validgh run list --jsonfieldIn
listWorkflowRunsWithPagination, the command requests:However, the
ghCLI'sRunFieldshas never includedpath. The valid fields are:This causes
ghto output:Notably, a regression test comment in
logs_github_api_test.goacknowledges a prior issue with this field:This suggests
pathwas intentionally re-added to thegh-awfield list to fix a filtering regression — but the field was never actually supported by theghCLI. It may have worked in some environments whereghsilently ignored unknown fields, but it fails in environments whereghrejects them.Bug 2: Error misclassification (case-sensitive string matching + overly broad heuristic)
The error handling in
listWorkflowRunsWithPaginationchecks for invalid field errors before auth errors, which is correct in principle:However, the
ghCLI outputs"Unknown JSON field"(capital U), andstrings.Containsis case-sensitive in Go. So"unknown field"does not match"Unknown JSON field", and the check is skipped.The code then falls through to the auth error check:
The
"exit status 1"heuristic matches becausegh run listexits with code 1 on the invalid field error, so the user sees a completely wrong "authentication required" message.Steps to Reproduce
gh).gh aw logs -vvv.🔍 Unknown JSON field: "path"✗ GitHub CLI authentication required. Run 'gh auth login' firstgh auth statusconfirms you are authenticated.Expected Behavior
gh-awshould not request JSON fields that theghCLI does not support.Proposed Fix
pathfrom thegh run list --jsonfield list (or replace it with an alternative approach to get the workflow file path, such as using the REST API orworkflowDatabaseId).strings.Contains(strings.ToLower(combinedMsg), "unknown field"))."exit status 1"heuristic — this is too broad and catches non-auth errors. Consider removing it or only matching when combined with auth-specific keywords.References
listWorkflowRunsWithPaginationerror handlingpathfieldRunFieldsincli/cli(nopathfield)