gh aw compile v0.68.1 pins actions/github-script@v9 to two different SHAs

[lupinthe14th]

Summary

gh aw compile (v0.68.1) generates lock workflows that pin actions/github-script@v9 to two different SHAs within the same workflow file:

• 373c709c69115d41ff229c7e5df9f8788daa9553 — used by exactly one step: Determine automatic lockdown mode for GitHub MCP Server
• 3a2844b7e9c422d3c10d287c895573f7108da1b3 — used by all other actions/github-script@v9 steps

The .github/aw/actions-lock.json manifest only records 373c… as the single v9 entry, but the gh-aw-manifest: header embedded at the top of each lock workflow lists both SHAs as separate entries:

{"repo":"actions/github-script","sha":"373c709c69115d41ff229c7e5df9f8788daa9553","version":"v9"},
{"repo":"actions/github-script","sha":"3a2844b7e9c422d3c10d287c895573f7108da1b3","version":"v9"}

This is reproducible across all 9 of our gh-aw workflows (daily-check, security-vulnerability-review, 6 security workers, test-skill).

Reproduction

1. Upgrade gh-aw extension to v0.68.1
2. Run gh aw compile on any repository with gh-aw workflows
3. Inspect the generated .lock.yml file: search for actions/github-script@

Both SHAs will appear in the uses: statements.

Expected behavior

All actions/github-script@v9 references should resolve to a single SHA. The actions-lock.json and the uses: statements in generated lock workflows should be consistent.

Impact

• Security review noise: PR review bots flag the inconsistency as a potential supply chain / reproducibility concern (Copilot raised 8 [must] comments on our PR)
• Audit complexity: Two SHAs for the same version tag complicates provenance tracking
• No functional issue observed yet — workflows execute successfully

Environment

• gh-aw CLI: v0.68.1
• gh-aw-actions/setup: v0.68.1
• Repository: private enterprise (ninout-ai/ent)
• Example workflow run: daily-check run #24438323938 (MCP registry 401 fix worked fine; inconsistency is cosmetic/audit-level)

Context

We upgraded from v0.67.0 to v0.68.1 to pick up the Copilot CLI v1.0.21 pin that fixes the MCP registry 401 regression (see gh-aw#25550, gh-aw#26069). The SHA inconsistency was not present in v0.67.0's lock output.

Happy to share full generated lock workflow if helpful (will need to redact org-specific secrets).