[aw-failures] Fix dev-mode gh-aw runtime step: `gh extension install .` missing `GH_TOKEN` — breaks every dev-mode `gh aw` workflow (PR #31622 [Content truncated due to length]

[github-actions]

Summary

PR #31622 (merged 2026-05-12 13:48 UTC) added a dev-mode gh aw runtime setup step that runs gh extension remove gh-aw || true; gh extension install .; gh aw version, without setting GH_TOKEN. gh extension install . shells out to gh and fails with the standard error:

gh: To use GitHub CLI in a GitHub Actions workflow, set the GH_TOKEN environment variable.

The step exits with code 4, the agent job fails, and the entire workflow run is marked failure. This already broke today's run of Static Analysis Report (a daily scheduled workflow). Two more dev-mode workflows carry the same defective step and will fail on their next schedule.

• Severity: P0 — daily-scheduled workflow regressed from 100% green to 100% red on the first run after the merge.
• Status: No existing tracking coverage. Filed as a sub-issue of the most recent open [aw-failures] parent report ([aw-failures] [aw] Failure Report 2026-05-11 (6h): aw-portfolio-yield workflow defect blocks compile + own runtime + recurrences [Content truncated due to length] #31455).

Affected workflows and runs

Workflow	Lock file step	Last known result	First failure
Static Analysis Report	static-analysis-report.lock.yml:441-445	Green daily 2026-05-04 → 2026-05-12 (§25716057035 succeeded 2026-05-12)	§25781225241 failed 2026-05-13 05:55 UTC, exit code 4
Copilot Token Audit	copilot-token-audit.lock.yml:436-440	(not yet run since PR #31622)	Will fail on next schedule
Copilot Token Optimizer	copilot-token-optimizer.lock.yml:405-409	(not yet run since PR #31622)	Will fail on next schedule

All three lock files were modified by PR #31622 and contain the identical generated step:

- name: Build and install gh-aw CLI from source
  run: |
    gh extension remove gh-aw || true
    gh extension install .
    gh aw version

The very next step in each file (Configure gh CLI for GitHub Enterprise) does pass GH_TOKEN: ${{ github.token }} — the new step was simply missed.

Root cause

pkg/workflow/runtime_step_generator.go:61-73 emits the dev-mode gh-aw setup step but never attaches an env: block:

if runtime.ID == "gh-aw" && !IsRelease() {
    step := GitHubActionStep{"      - name: Build and install gh-aw CLI from source"}
    if req.IfCondition != "" {
        step = append(step, "        if: "+req.IfCondition)
    }
    step = append(step,
        "        run: |",
        "          gh extension remove gh-aw || true",
        "          gh extension install .",
        "          gh aw version",
    )
    return step
}

gh extension install . (and the preceding gh extension remove) invoke gh, which refuses to run without GH_TOKEN/GITHUB_TOKEN in a GitHub Actions context.

Failure excerpt — run 25781225241 / agent job

##[group]Run gh extension remove gh-aw || true
gh extension remove gh-aw || true
gh extension install .
gh aw version
...
gh: To use GitHub CLI in a GitHub Actions workflow, set the GH_TOKEN environment variable. Example:
  env:
    GH_TOKEN: ${{ github.token }}
gh: To use GitHub CLI in a GitHub Actions workflow, set the GH_TOKEN environment variable. Example:
  env:
    GH_TOKEN: ${{ github.token }}
##[error]Process completed with exit code 4.

Why this didn't show up in PR validation

PR #31622's validation ran targeted workflow runtime tests for detection and setup-step generation plus code review + CodeQL. Those checks do not execute the generated step against a real Actions runner, and the existing assertion in pkg/workflow/runtime_step_generator.go tests only verifies that the literal string gh extension install . appears in the rendered YAML — it does not assert anything about the surrounding env: block.

Proposed remediation

Fix the generator so every dev-mode gh-aw setup step carries env: GH_TOKEN: ${{ github.token }} (and GITHUB_TOKEN if needed for parity with the next step), then re-compile the three affected lock files.

Specifically:

1. In pkg/workflow/runtime_step_generator.go, append:

   "        env:",
   "          GH_TOKEN: ${{ github.token }}",
   

   to the dev-mode branch before return step.
2. Re-run gh aw compile so the three .lock.yml files pick up the env block.
3. Add a unit test in pkg/workflow/runtime_gh_aw_test.go (or a new test) asserting the dev-mode step contains GH_TOKEN: ${{ github.token }}.
4. Verify by re-running Static Analysis Report via workflow_dispatch on the fix branch.

Success criteria

• pkg/workflow/runtime_step_generator.go emits env.GH_TOKEN for the dev-mode gh-aw step.
• Unit test guarding the env block lands alongside the fix.
• The three .lock.yml files contain GH_TOKEN: ${{ github.token }} on the Build and install gh-aw CLI from source step.
• Manual workflow_dispatch of Static Analysis Report on the fix branch completes with conclusion success.
• The next scheduled Static Analysis Report run after merge is green.

Related

• Regression introduced by PR #31622 — Treat gh aw as a first-class runtime with release setup-cli injection, dev source build, and firewall domains.
• Parent report: [aw-failures] [aw] Failure Report 2026-05-11 (6h): aw-portfolio-yield workflow defect blocks compile + own runtime + recurrences [Content truncated due to length] #31455.

References:

• §25781225241 (failed Static Analysis Report — 2026-05-13)
• §25716057035 (last green Static Analysis Report — 2026-05-12)
  Related to [aw-failures] [aw] Failure Report 2026-05-11 (6h): aw-portfolio-yield workflow defect blocks compile + own runtime + recurrences [Content truncated due to length] #31455

Generated by [aw] Failure Investigator (6h) · ● 15.1M · ◷

• expires on May 20, 2026, 7:53 AM UTC

[github-actions]

🍪 Issue Monster selected this for Copilot

I've identified this issue as a good candidate for automated resolution and requested assignment to the Copilot coding agent.

If assignment succeeds, the Copilot coding agent will analyze the issue and create a pull request with the fix.

Om nom nom! 🍪

🍪 Om nom nom by Issue Monster · ● 60.7K · ◷