fix: check binary existence for gh-aw install instead of gh aw --version

[Copilot]

Fixes #2163

Root Cause

The "Install gh-aw extension" step in shared/mcp/gh-aw.md was using gh aw --version to detect whether the extension was already installed:

if ! gh aw --version >/dev/null 2>&1; then
  # install...
fi

Newer gh CLI versions now return exit code 0 for gh aw --version even when the extension is not installed, printing "gh aw is available as an official extension. To install it, run: gh extension install github/gh-aw". This caused the install block to be silently skipped, after which the binary search failed with "Failed to find gh-aw binary for MCP server".

Evidence from CI logs (run 24830751736):

• Total step execution time was ~80ms — too fast for curl/install to have run
• Only output was the "available as official extension" message followed immediately by the error
• No "Installing gh-aw extension..." or install script output visible

Fix

Changed the detection logic to check for binary existence instead of relying on gh aw --version exit code. Binary existence is the reliable source of truth:

GH_AW_BIN=$(which gh-aw 2>/dev/null || find "${HOME}/.local/share/gh/extensions/gh-aw" -name 'gh-aw' -type f 2>/dev/null | head -1)
if [ -z "$GH_AW_BIN" ] || [ ! -f "$GH_AW_BIN" ]; then
  # install...
  # refresh GH_AW_BIN after install
fi

The binary path variable is also refreshed after installation so the copy step reuses it without a redundant search.

Files Changed

• shared/mcp/gh-aw.md — source fix
• All lock files regenerated via gh aw compile + post-processing script

[Copilot]

Pull request overview

This PR aims to fix unreliable detection of the gh-aw GitHub CLI extension in the shared MCP install step by checking for the gh-aw binary’s existence rather than relying on gh aw --version’s exit code (which can be 0 even when not installed).

Changes:

• Update .github/workflows/shared/mcp/gh-aw.md to detect installation via gh-aw binary presence and refresh the resolved path after installing.
• Regenerate multiple compiled workflow lock files.

Show a summary per file

File	Description
.github/workflows/shared/mcp/gh-aw.md	Switches install detection to binary-existence checks and reuses the resolved binary path after install.
.github/workflows/update-release-notes.lock.yml	Regenerated lock file; now includes manifest/action pinning changes that need correction.
.github/workflows/smoke-gemini.lock.yml	Regenerated lock file; now includes manifest/action pinning changes that need correction.
.github/workflows/security-review.lock.yml	Regenerated lock file; now includes manifest/action pinning changes that need correction.
.github/workflows/firewall-issue-dispatcher.lock.yml	Regenerated lock file; now includes manifest/action pinning changes that need correction.
.github/workflows/cli-flag-consistency-checker.lock.yml	Regenerated lock file; now includes manifest/action pinning changes that need correction.
.github/workflows/ci-doctor.lock.yml	Regenerated lock file; now includes manifest/action pinning changes that need correction.
.github/workflows/ci-cd-gaps-assessment.lock.yml	Regenerated lock file; now includes manifest/action pinning changes that need correction.
.github/workflows/agentics-maintenance.yml	Regenerated workflow; includes an apparent gh-aw tooling/action version downgrade relative to prior state.
.github/aw/actions-lock.json	Removes gh-aw-actions entries; likely contributes to inconsistent/unpinned workflow compilation outputs.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comments suppressed due to low confidence (1)

.github/aw/actions-lock.json:47

• .github/aw/actions-lock.json no longer contains entries for github/gh-aw-actions/setup / setup-cli, yet workflows in this PR reference those actions. If this file is used as the source of truth for action pinning/upgrades, it should include the gh-aw-actions entries (with commit SHAs) that match the workflow refs to avoid future upgrades/compiles producing unpinned or inconsistent lock files.

    "github/gh-aw/actions/setup@v0.69.3": {
      "repo": "github/gh-aw/actions/setup",
      "version": "v0.69.3",
      "sha": "6abd7107cebd8b300f4d64013201ad2d8e0a994f"
    },

• Files reviewed: 28/32 changed files
• Comments generated: 9

[Copilot]

The gh-aw-manifest entry for github/gh-aw-actions/setup sets sha to v0.68.3 (a tag) instead of a commit SHA. These lock files previously pinned actions by commit SHA; using a tag here defeats locking and may break any tooling that expects sha to be a real commit digest. Please regenerate the lock file(s) so sha is a commit SHA and uses: references are pinned consistently.

[Copilot]

The gh-aw-manifest entry for github/gh-aw-actions/setup sets sha to v0.68.3 (a tag) instead of a commit SHA. These lock files previously pinned actions by commit SHA; using a tag here defeats locking and may break any tooling that expects sha to be a real commit digest. Please regenerate the lock file(s) so sha is a commit SHA and uses: references are pinned consistently.

[Copilot]

This PR is described as a narrow fix to gh-aw install detection, but this workflow also downgrades the gh-aw action/tooling version (e.g., generator version and github/gh-aw-actions/* refs) compared to the prior state. If the downgrade is unintentional, please regenerate with the repo’s intended gh-aw version so the maintenance workflow doesn’t drift independently of other workflows.

[Copilot]

GH_AW_BIN detection uses which and only checks -f, so a non-executable file (or an unexpected match from find) can cause the install step to be skipped and later fail at runtime. Consider using command -v gh-aw and validating -x "$GH_AW_BIN" (and/or find ... -executable) before treating the binary as present and copying it.

See below for a potential fix:

      GH_AW_BIN=$(command -v gh-aw 2>/dev/null || find "${HOME}/.local/share/gh/extensions/gh-aw" -name 'gh-aw' -type f -executable 2>/dev/null | head -1)
      if [ -z "$GH_AW_BIN" ] || [ ! -x "$GH_AW_BIN" ]; then
        echo "Installing gh-aw extension..."
        # Download to a temp file first so curl failures are detected (avoids silent pipe failure)
        curl -fsSL https://raw.githubusercontent.com/github/gh-aw/refs/heads/main/install-gh-aw.sh -o /tmp/install-gh-aw.sh
        bash /tmp/install-gh-aw.sh
        rm -f /tmp/install-gh-aw.sh
        GH_AW_BIN=$(command -v gh-aw 2>/dev/null || find "${HOME}/.local/share/gh/extensions/gh-aw" -name 'gh-aw' -type f -executable 2>/dev/null | head -1)
      fi
      gh aw --version
      # Copy the gh-aw binary to RUNNER_TEMP for MCP server containerization
      mkdir -p "${RUNNER_TEMP}/gh-aw"
      if [ -n "$GH_AW_BIN" ] && [ -x "$GH_AW_BIN" ]; then

[Copilot]

The gh-aw-manifest entry for github/gh-aw-actions/setup sets sha to v0.68.3 (a tag) instead of a commit SHA. These lock files previously pinned actions by commit SHA; using a tag here defeats locking and may break any tooling that expects sha to be a real commit digest. Please regenerate the lock file(s) so sha is a commit SHA and uses: references are pinned consistently.

[Copilot]

The gh-aw-manifest entry for github/gh-aw-actions/setup sets sha to v0.68.3 (a tag) instead of a commit SHA. These lock files previously pinned actions by commit SHA; using a tag here defeats locking and may break any tooling that expects sha to be a real commit digest. Please regenerate the lock file(s) so sha is a commit SHA and uses: references are pinned consistently.

[Copilot]

The gh-aw-manifest entry for github/gh-aw-actions/setup sets sha to v0.68.3 (a tag) instead of a commit SHA. These lock files previously pinned actions by commit SHA; using a tag here defeats locking and may break any tooling that expects sha to be a real commit digest. Please regenerate the lock file(s) so sha is a commit SHA and uses: references are pinned consistently.

[Copilot]

The gh-aw-manifest entry for github/gh-aw-actions/setup sets sha to v0.68.3 (a tag) instead of a commit SHA. These lock files previously pinned actions by commit SHA; using a tag here defeats locking and may break any tooling that expects sha to be a real commit digest. Please regenerate the lock file(s) so sha is a commit SHA and uses: references are pinned consistently.

[Copilot]

The gh-aw-manifest entry for github/gh-aw-actions/setup sets sha to v0.68.3 (a tag) instead of a commit SHA. These lock files previously pinned actions by commit SHA; using a tag here defeats locking and may break any tooling that expects sha to be a real commit digest. Please regenerate the lock file(s) so sha is a commit SHA and uses: references are pinned consistently.

[lpcox]

@copilot address this review feedback #2183 (review)

[Copilot]

@copilot address this review feedback #2183 (review)

Addressed in a118959:

1. command -v + -executable + -x: Updated shared/mcp/gh-aw.md to use command -v gh-aw instead of which, added -executable to the find call, and changed the guard condition from -f to -x (including the final copy check). This ensures a non-executable file isn't mistaken for a valid binary.

2. Lock file sha using tag instead of commit SHA: The root cause was that my first compile run (with the wrong gh-aw version) removed the github/gh-aw-actions/setup@v0.69.3 and github/gh-aw-actions/setup-cli@v0.69.3 entries from actions-lock.json. Without those entries, the compiler falls back to using the tag name as-is instead of resolving it to the commit SHA. I restored those entries and recompiled all workflows with gh-aw v0.69.3 — all manifest sha values are now proper commit SHAs (006ffd856b868b71df342dbe0ba082a963249b31).

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• https://api.github.com/repos/actions/github-script/git/ref/tags/v9
  • Triggering command: /usr/bin/gh gh api /repos/actions/github-script/git/ref/tags/v9 --jq [.object.sha, .object.type] | @tsv (http block)
  • Triggering command: /usr/bin/gh gh api /repos/actions/github-script/git/ref/tags/v9 --jq [.object.sha, .object.type] | @tsv developer-action-main/dist/indexgpg.program (http block)
• https://api.github.com/repos/github/gh-aw-actions/git/ref/tags/v0.69.3
  • Triggering command: /usr/bin/gh gh api /repos/github/gh-aw-actions/git/ref/tags/v0.69.3 --jq [.object.sha, .object.type] | @tsv (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[github-actions]

🔥 Smoke Test Results

• ✅ GitHub MCP — Latest merged PR: "feat(api-proxy): add startup API key validation" (feat(api-proxy): add startup API key validation #2200)
• ✅ GitHub.com Connectivity — HTTP 200
• ✅ File Write/Read — smoke-test-copilot-24906816547.txt verified

Overall: PASS

PR author: @app/copilot-swe-agent | Assignees: @lpcox, @Copilot

📰 BREAKING: Report filed by Smoke Copilot

[github-actions]

Smoke Test Results: ✅ PASS

• ✅ GitHub MCP: feat(api-proxy): add startup API key validation #2200, fix(api-proxy): strip all Gemini auth query param variants to prevent API_KEY_INVALID #2182
• ✅ Playwright: GitHub page loaded
• ✅ File I/O: Test file created
• ✅ Bash: Verification passed

💥 [THE END] — Illustrated by Smoke Claude

[github-actions]

Smoke Test: Copilot BYOK (Offline) Mode — PASS

Test	Result
GitHub MCP (list merged PRs → #2200 "feat(api-proxy): add startup API key validation")	✅
GitHub.com connectivity	✅
File write/read (smoke-test-copilot-byok-24906816546.txt)	✅
BYOK inference (agent → api-proxy → api.githubcopilot.com)	✅

Running in BYOK offline mode (COPILOT_OFFLINE=true) via api-proxy → api.githubcopilot.com.
Author: @app/copilot-swe-agent · Assignees: @lpcox, @Copilot · Overall: PASS

🔑 BYOK report filed by Smoke Copilot BYOK

[github-actions]

Smoke test summary
"fix: check binary existence for gh-aw install instead of gh aw --version"
"Revise blog post draft on GitHub Agentic Workflows"
Tests: 1✅ 2❌ 3✅ 4❌
Tests: 5✅ 6✅ 7❌ 8✅
Overall status: FAIL

Warning

⚠️ Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• registry.npmjs.org

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "registry.npmjs.org"

See Network Configuration for more information.

🔮 The oracle has spoken through Smoke Codex

[github-actions]

🏗️ Build Test Suite Results

⚠️ ALL CLONES FAILED — Unable to clone any test repositories.

All gh repo clone attempts failed with:

remote: access denied: unrecognized endpoint
fatal: unable to access '(localhost/redacted) The requested URL returned error: 403

Ecosystem	Project	Build/Install	Tests	Status
Bun	elysia	❌	N/A	❌ CLONE_FAILED
Bun	hono	❌	N/A	❌ CLONE_FAILED
C++	fmt	❌	N/A	❌ CLONE_FAILED
C++	json	❌	N/A	❌ CLONE_FAILED
Deno	oak	❌	N/A	❌ CLONE_FAILED
Deno	std	❌	N/A	❌ CLONE_FAILED
.NET	hello-world	❌	N/A	❌ CLONE_FAILED
.NET	json-parse	❌	N/A	❌ CLONE_FAILED
Go	color	❌	N/A	❌ CLONE_FAILED
Go	env	❌	N/A	❌ CLONE_FAILED
Go	uuid	❌	N/A	❌ CLONE_FAILED
Java	gson	❌	N/A	❌ CLONE_FAILED
Java	caffeine	❌	N/A	❌ CLONE_FAILED
Node.js	clsx	❌	N/A	❌ CLONE_FAILED
Node.js	execa	❌	N/A	❌ CLONE_FAILED
Node.js	p-limit	❌	N/A	❌ CLONE_FAILED
Rust	fd	❌	N/A	❌ CLONE_FAILED
Rust	zoxide	❌	N/A	❌ CLONE_FAILED

Overall: 0/8 ecosystems passed — ❌ FAIL

Error details: The gh CLI proxy sidecar returned 403 access denied: unrecognized endpoint for all Mossaka/gh-aw-firewall-test-* repositories. This likely means these repositories are not accessible from this runner environment (private repos the proxy doesn't recognize, or repositories don't exist).

Generated by Build Test Suite for issue #2183 · ● 121.9K · ◷

[github-actions]

Smoke Test Results: GitHub Actions Services Connectivity

Check	Result
🔴 Redis (host.docker.internal:6379) — redis-cli PING	FAILED — redis-cli not installed; port unreachable (timeout)
🔴 PostgreSQL ready (host.docker.internal:5432) — pg_isready	FAILED — no response (exit 2)
🔴 PostgreSQL query (SELECT 1) — psql	FAILED — port unreachable (timeout)

host.docker.internal resolves to 172.17.0.1 but neither service port is reachable from this runner. Services may not have started or are not bound to the Docker bridge interface.

🔌 Service connectivity validated by Smoke Services