[aw-compat] Daily AW compat audit (2026-08-05): opencode engine removal has no migration codemod; 4 --strict findings are test-harness artif [Content truncated due to length]

[github-actions]

Overview

Daily cross-repo compatibility audit: compiled the top 20 public repositories using gh-aw against today's local build (gh aw version 80b45ff, main).

Metric	Value
Repos discovered (verified .lock.yml present)	92
Repos selected (top by stars)	20
Clone success	20/20
compile --strict failures (initial)	6/20
Resolved automatically by gh aw fix --write	1/20 (githubnext/agentics-template)
Genuine unresolved compatibility break	1/20 (srinitude/pi-until-done)
--strict-only artifacts (pass with plain compile)	4/20

Key finding: missing codemod for removed opencode engine

srinitude/pi-until-done (.github/workflows/pi-runtime-review.md) declares engine: { id: opencode } and fails to compile:

.github/workflows/pi-runtime-review.md:22:1: error: invalid engine: opencode. Valid engines are: claude, codex, copilot, gemini, pi.

gh aw fix --write reports "No fixes needed" for this file — there is no automatic migration.

CHANGELOG.md independently confirms this is an intentional, unreleased breaking change:

Removed the experimental opencode engine

Workflows using engine: opencode must migrate to copilot, claude, codex, gemini, antigravity, or pi. The runner no longer restores opencode.jsonc or .opencode/ configuration.

Suggested fix: add a codemod to gh aw fix that detects engine.id: opencode and either rewrites it to a safe default (e.g. copilot) with a warning comment, or at minimum emits actionable fix guidance instead of leaving the workflow permanently broken with no remediation path. Only 1/20 sampled repos hit this, but it's confirmed as a real, currently-shipping breaking change, so it will likely affect other downstream repos not in this sample.

Full clean-run vs. --strict-only distinction (why only 1 repo is a real bug)

4 of the 6 initial --strict failures are not compatibility bugs — they are smoke-test/example repos that intentionally ship strict: false workflows exercising disallowed sandbox/security configurations (sudo mode, disabled agent firewall, sink-visibility bypass, raw MCP container access). The --strict CLI flag is documented to override any per-workflow strict: false, so forcing it during this audit surfaces these by design. Verified by recompiling each without --strict:

Repo	Under --strict	Under plain compile
github/gh-aw-mcpg	1 workflow failed	36/36 succeeded
github/gh-aw-firewall	2 workflows failed	64/64 succeeded
githubnext/gh-aw-test	14 workflows failed	115/115 succeeded
elastic/ai-github-actions	2 workflows failed	57/57 succeeded

No action needed on these — flagging only so the pattern isn't mistaken for a regression in a future run. Recommend future audits use plain gh aw compile as the primary pass/fail signal and treat --strict as a separate, clearly labeled security-posture check.

Working codemods observed (no action needed, included for confirmation)

• engine.model → top-level model: deprecated-field warning triggered in 6/20 repos (Hack23/euparliamentmonitor, chrizbo/agentics-beyond-code, elastic/ai-github-actions, github/gh-aw-threat-detection, githubnext/gh-aw-test, shyamagu-ms/ai-scrum) — gh aw fix --write auto-fixed every occurrence cleanly.
• Top-level roles: → on.roles: githubnext/agentics-template's q.md had roles: [admin, maintainer, write] at the wrong nesting level; gh aw fix --write moved it automatically, turning a compile failure into a clean pass.
• top-level-env-secrets-guided-error codemod in github/gh-aw-firewall: correctly declined to auto-move secrets (OPENAI_API_KEY, AZURE_CLIENT_ID, AZURE_TENANT_ID) out of top-level env: for 3 files, printing manual-fix guidance instead of silently rewriting security-sensitive config. This is the right behavior, not a bug.

Recurring non-blocking warning

"Prompt references /tmp/ directly. Use /tmp/gh-aw/agent/ as the root..." appeared across 5/20 repos (elastic/ai-github-actions, github/gh-aw-firewall, github/gh-aw-mcpg, github/gh-aw, githubnext/ado-aw). Purely informational; no compile failures resulted.

Method notes for future runs

• gh search code (the discovery method in the runbook) returned persistent HTTP 429 in this sandbox for every query tested, including queries unrelated to gh-aw, across multiple retries with increasing backoff. Fell back to gh search repos (topic/readme text queries) to build a ~188-repo candidate pool, then verified real gh-aw usage per-candidate via gh api repos/{owner}/{repo}/contents/.github/workflows, filtering to repos with at least one *.lock.yml file.
• Caught and fixed a verification bug mid-run: naively treating any non-empty API response as a valid file listing counted GitHub's 404 error body (which happens to have exactly 3 JSON keys: message, documentation_url, status) as "3 lock files present." This produced ~45 false-positive candidates (unrelated repos like flag-icon libraries, holiday-date libraries, a Tor proxy tool) before the fix validated the response is actually a JSON array.
• Selected top 20 by star count from the corrected, verified candidate list of 92 repos.

References

• github/gh-aw-mcpg
• github/gh-aw-firewall
• srinitude/pi-until-done

Generated by 🔧 Daily AW Cross-Repo Compile Check · agent · 209.6 AIC · ⌖ 40.5 AIC · ⊞ 5.3K · ◷

• expires on Aug 12, 2026, 2:02 AM UTC-08:00

[github-actions]

This issue is being closed as outdated. A newer issue has been created: #50829

View newer issue

---

This action was performed automatically by the Daily AW Cross-Repo Compile Check workflow.