Work around gh-aw cached Copilot path

[David Pine (IEvangelist)]

Description

gh-aw v0.85.4 can select a cached GitHub Copilot CLI from the hosted runner toolcache while its generated AWF command still invokes /usr/local/bin/copilot. The mismatch causes the agent or threat-detection job to fail with ENOENT before producing output.

This stages the checksum-verified standalone CLI selected by gh-aw at the path its v0.85.4 harness expects. The agent job stages it after the generated installer. Because threat detection runs on a fresh runner and its extension steps precede the generated installer, that job first invokes the same gh-aw installer and then stages the selected binary. The workaround remains limited to the PR documentation workflow and includes removal guidance for github/gh-aw#50908.

Related:

• github/gh-aw#50906
• microsoft/aspire#19054

Validation:

• Recompiled all eight agentic workflows with gh-aw v0.85.4.
• gh aw compile --validate --strict completed successfully for all eight workflows.
• Confirmed .github/aw/actions-lock.json is unchanged and the safe-output jobs retain contents: write.
• Recovery run 31145729695 selected cached Copilot CLI 1.0.77 in both jobs, staged and executed it successfully, passed agent, detection, and safe output, and created microsoft/aspire.dev#1435. The overall run failure is the expected notification-only 403 because source PR Flush logs before terminal resource notifications #18539 is locked.

Fixes # (issue)

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 19109

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 19109"

[Copilot]

Pull request overview

Adds a targeted gh-aw v0.85.4 workaround so PR documentation agent and threat-detection jobs can locate the cached GitHub Copilot CLI.

Changes:

• Stages the selected CLI at /usr/local/bin/copilot.
• Applies the workaround to both agent execution and threat detection.
• Regenerates the compiled workflow.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
.github/workflows/pr-docs-check.md	Defines the temporary CLI staging workaround.
.github/workflows/pr-docs-check.lock.yml	Contains the recompiled workflow changes.

[aspire-repo-bot]

✅ No documentation update needed.

Step 5 branch taken: docs_required → false positive, no concrete documentation edit

Triggered signals (1): pr_body_has_cli_flag_mention — evidence: "gh aw compile --validate --strict completed successfully for all eight workflows." from the PR body.

Why this is a false positive: The matched "CLI flag mention" is gh aw compile --validate --strict, a validation command for the internal gh-aw GitHub Actions tooling (github/gh-aw), not an Aspire CLI flag or any Aspire user-facing feature. The PR itself only modifies two files, both under .github/workflows/ (pr-docs-check.lock.yml, pr-docs-check.md) — a workaround for a gh-aw/Copilot CLI path caching bug in this repo's own agentic-workflow CI infrastructure. This has no effect on any behavior, API, CLI, or output documented on microsoft/aspire.dev; it also independently satisfies the docs_optional allowlist category build_or_ci_only (100% of changed files under .github/workflows/).

No documentation changes are needed on microsoft/aspire.dev for this change.